리액트의 이벤트 리스너
-
리액트는 컴포넌트 함수가 처음 실행될때 JSX 코드를 딱 한번만 가져간다.
-
그렇기 때문에 기존 js 처럼 이벤트 리스너를 추가하면 무시당한다
-
useState 란 리액트 훅을 사용!
-
상태 업데이트 함수가 호출되면 React는 해당 함수를 다시 호출하지 않습니다. 대신 구성 요소의 다시 렌더링을 트리거합니다.
-
그런 다음 React는 새로운 가상 DOM을 이전 가상 DOM과 비교하고 그에 따라 실제 DOM을 업데이트합니다.
children prop
-
컴포넌트를 다른 컴포넌트로 래핑하고 거기에 다른 스타일을 적용하는 방식을 사용
-
구성 요소의 동적 구성을 가능하게 한다. 콘텐츠와 긴밀하게 연결되지 않은 일반적이고 재사용 가능한 구성 요소를 만드는 것이 가능합니다.
배열 JSX 매핑
- key 라는 특수 프로퍼티를 JSX 요소에 추가해야한다.
useState vs useEffect
useState
- 이전에는 클래스 컴포넌트에서만 state를 사용할 수 있었습니다.
- 함수형 컴포넌트에 상태 관리를 추가할 수 있는 훅
useEffect(() => {
async function fetchPosts() {
const response = await fetch('http://localhost:8080/posts')
const resData = await response.json();
setPosts(resData.posts);
}
fetchPosts();
}, []);-
- 구성 요소가 처음 마운트될 때 서버에서 데이터를 가져온 다음 해당 데이터로 구성 요소의 상태를 업데이트합니다.
-
- 'useEffect' 후크의 빈 종속성 배열은 클래스 구성요소의 'comComponentDidMount' 동작을 모방하여 데이터 가져오기 로직이 한 번만 실행되도록 하는 방법입니다.
목적
- 컴포넌트의 로컬 상태를 관리하고 추적하기 위해
정리
- 컴포넌트의 상태에 따라 컴포넌트의 뷰가 어떻게 보이고 동작해야 하는지를 관리하는 것
const [state, setState] = useState(initialState);
useEffect
- 함수형 컴포넌트에서 사이드 이펙트를 수행할 수 있는 훅
목적
- 렌더링과 직접 관련이 없는 작업인 데이터 불러오기, 구독 또는 수동으로 DOM을 변경하는 것과 같은 부작용을 처리합니다.
useEffect(() => {
// Side effect logic here
return () => {
// Cleanup logic here
};
}, [dependencies]);
정리
- 변경의 결과로 어떤 일이 일어나야 하는지에 관한 것으로, 종종 컴포넌트 자체를 넘어 월드에까지 영향을 미칩니다.
리액트 라우터
경로
- URL 경로에 따라 UI 구성요소를 렌더링합니다. 현재 URL을 해당 경로와 일치시키고 적절한 구성 요소를 렌더링한다.
링크
- 애플리케이션에서 링크를 만드는 데 사용됩니다. 이를 통해 애플리케이션에 정의된 다양한 경로로 이동할 수 있습니다. a 태그 대신 Link를 사용하면 페이지가 다시 로드되는 것을 방지할 수 있습니다.
import React from 'react';
import { BrowserRouter as Router, Route, Link, Switch } from 'react-router-dom';
function App() {
return (
<Router>
<div>
<nav>
<Link to="/">Home</Link>
<Link to="/about">About</Link>
</nav>
<Switch>
<Route exact path="/">
<Home />
</Route>
<Route path="/about">
<About />
</Route>
</Switch>
</div>
</Router>
);
}
function Home() {
return <h2>Home Page</h2>;
}
function About() {
return <h2>About Page</h2>;
}
export default App;
- 예시에서 링크를 클릭하면 URL이 변경되고
- 페이지를 다시 로드하지 않고도 해당 구성 요소가 렌더링됩니다.
팀스터디 알고리즘 회고
프로그래머스 타겟 넘버
멘토링 QnA
Q. 리액트로 프로젝트를 할 떄 "어떤 기준으로 컴포넌트를 나눌 것인지"에 대한 고민을 많이 하는데, 컴포넌트를 너무 세분화하게 되면 상태관리나 props관리가 복잡해지고(+리렌더링), 그 반대는 확장성이 너무 커진다는 문제가 있었습니다. 멘토님은 주로 어떤 디자인 패턴을 적용해 컴포넌트를 구성하시는지 궁금합니다.
-
컴포넌트를 만들다 보면 재사용성을 계획하면서 만들게 돼. 재사용성을 위해 하다보면 복잡하게 되고,
-
가능하다면 화면상의 구성요소 단위로 컴포넌트 재사용률이 높은 컴퍼넌트를 만들려고 하는편. 아주 작은 구성요소까지 나누는건 선호하지 않아. 재사용성을 위해 작게 만들다보면 결국 퀄리티가 떨어져.
Q. 좋은 개발자는 “회고를 잘 하는 개발자” 라고 말씀해 주신 부분이 기억 남습니다.멘토님도 프로젝트들을 경험하면서 수많은 회고를 하셨을 것 같습니다. KPT 회고, 4L 회고 ,5F 회고 등 다양한 회고 방식이 있는데 멘토님은 어떤 방식으로 회고를 하고 계신지 궁금하고 그 이유도 알려주시면 감사하겠습니다.
-
회고를 하기 위한 기록까지가 좋은 거라고 생각해. 기록을 적다보면 날것이라도 가치가 크다! KPT 가 저 중에서는 가장 좋은거같아. 저걸 100퍼 준수하지는 않지만 저런 느낌으로 하긴해.
-
저런 방법론들의 키 포인트는 '요약을 잘해라' 야. 저런 개념으로 접근하는게 좋을거같아. 무슨 방식으로 회고를 했습니다 보다는 하다보니 저런 방식이 되는게 좋은거같아.
Q. 개발자 직업의 가장 좋은 점은 공유 문화라고 생각합니다. 그래서인지 다양한 컨퍼런스 (우아콘,Dev Day 등 ) 이 열리는 것 같습니다. 멘토님이 생각하시기에 이런 컨퍼런스들에 참여하는 것을 어떻게 보시는지 궁금합니다. 또 개인적으로 추천해주실만한 개발자 행사나 컨퍼런스가 있는지도 궁금합니다.
-
컨퍼런스에서 요약본도 많지만, 내가 요약해보는게 중요한거같아. 그게 사실은 항상 정답은 아니기 때문. 어떤 메세지를 줄려고 했을까?
-
IT 회사에서 하는 컨퍼런스는 다 괜찮은거같아. 근데, 에반젤리스트들의 컨퍼런스는 그냥 세일즈 하는 강의 같아서 개인적으로 별로 추천을 하지는 않아.
-
오프라인 티켓은 구하기 어려운데, 구하게 되면 한번쯤 가는걸 추천해. 오프라인은 끝나고 질문도 가능하니 기회가 더 많아서 좋은거같아.
-
추가적으로 토스, NHN, 네이버, 카카오, 등등 본인들 회사 이름 걸고하는곳은 정말 퀄리티가 좋았어.
Q. 1. 3개월이라는 부트캠프 기간 동안 과정을 열심히 따랐을 때, 개발자로 커리어 전환이 현실적으로 가능성이 있을지 걱정이 앞섭니다. 지금까지 개발자로 커리어 전환한 사람들을 여럿 보셨을텐데 보통 어느정도 기간을 공부했는지 궁금합니다.
- 학습 효율이나 결과물를 높이기 위한 접근이 더 중요하다고 생각해. 얼만큼을 실제 실력으로 치환하는지.
Q. 2. 프론트 / 백 진로를 결정하는 절대적인 기준은 없겠지만 진로를 결정할 때 도움이 될 기준이 있을지 궁금합니다.
- 변화를 좋아하고, 시각적인 자극, 다이나믹을 좋아한다 => 프론트.
- 스테이블하고, 세심한 성향 => 백엔드
Q. CS과목 학습 우선순위에 관한 질문입니다! (OS = 데이터베이스 = 네트워크) > 컴퓨터 구조 > 보안(우선은 얕게) 위 순서로 계획을 잡아두고 공부를 하고 있습니다! 1. 여기에 추가하거나 일단은 빼둬도 괜찮을 주제가 있을지 2. 우선순위에 조정이 필요하다면 어떻게 하면 좋을지. 3. 추가적으로 주니어 백엔드 개발자가 실무에서 바로 활용하는 기술(스프링 프레임워크 등)에 대한 학습과의 우선순위를 비교하자면 무엇이 우선이 되어야 할까요?!
-
DB 가 가장 우선순위. 백엔드 개발자는 데이터베이스 중개자이기 때문. 데이터 베이스를 가지고 일을 하는게 일의 90퍼센트 이기 때문에.
-
특히 데이터베이스 정합성을 중요하게 생각하는 핀테크 회사는 DB 가 100프로 가장 중요해.
-
그 뒤를 보면 OS=네트워크 > 컴퓨터구조 > 보안(위시리스트).
-
- mysql 성능 이슈를 만들어서 이를 풀다보면, 성능 테스트 툴의 사용법도 늘고.
-
스프링 책을 계속 봐야지~ 이건 매우 별로야,. 실습을 한참 한뒤에 책을 읽는게 좋아.
-
그냥 책만 읽는 상태는 제일 안좋은 결과야. 무조건 실습쪽으로 시간을 두는게 좋아.
Q. 기본적인 학습이 되어있으면 바로 실습하는게 좋다고 하셨는데, 스프링 MVC 는 많이 했지만, DB 가 부족하다면 어떤 커리큘럼으로 가야할지?
-
개인적으로 실습을 바로 하는게 좋은 방식이라고 생각하지만, 개인마다 다를 수 있다.
-
나만의 학습 방식을 찾아야해.
Q. 이전에 포트폴리오에서 프로젝트에서 어떤 이슈를 만났고, 이를 어떻게 해결했는지 관심있게 보신다고 하셨는데, 프로젝트를 진행하면서 트러블 슈팅에 대해 문서화하여 정리하는 것이 쉽지 않았습니다. 멘토님께서는 프로젝트 중간중간 문서화로 정리하시는지, 아니면 키워드만 미리 적어두고 프로젝트 끝나고 정리하시는지 궁금합니다! 그리고 문서화를 귀찮아하지 않고, 꾸준히 잘 쓸 수 있는 방법이 있을지도 궁금합니다 ㅎㅎ
-
이슈가 여러개가 터질 수 있고 해서 기록을 좀 늘리기 시작했어. 이직을 할때도 기록을 다 남겨놓으면 매우 좋고. 퇴근길에 이슈를 정리를 하는거야.
-
CI/CD 가 요즘에 필수적인데, 난 귀찮아서 이를 자동화했어.
-
문서화는 습관이 되어있어야해. 다른건 자동화가 되도 얘는 안되거든.
Q. 개발자 분들중에서 Notion이나 Obsidian github 블로그 등의 툴과 플랫폼을 활용해서 본인만의 지식을 관리하고 second brain화 하는 분들을 많이 봐왔습니다..! 저는 처음에는 블로그를 써오다가 어떤 생각이 떠올랐을때 마음먹지 않고 빠르게 기록해놓을수 있는 Notion으로 툴을 바꾸었다가.> 최근에는 노션이 반응이 너무느려져서 Obsidian으로 옮겨온 유목민인데요..! 기록 유목민으로써, 강사님은 어떤 툴을 사용하시는지 궁금합니다..!
-
노션을 쓰다가 => 옵시디언에 정착했음. 퇴근하고 한두시간씩 스크래핑부터 해서 옵시디언에 다 옮겼음.
-
옵시디언 플러그인이 되게 강력해. 커스터마이징도 되고.
Q. 혹시 멘토님이 추천하시는 옵시디언 플러그인이 있을까요?
Advanced Tables, Banners, Book Search, Caelendar, Chronology, Custom Attachment Location, Day Planner, Diagrams.net, Enhancing Mindmap, Excalidraw, Game Search, Iconize, Kanban, Media DB Plugin, Mermaid Tools, Mind Map, Outliner, PlantUML, ReaditLater, Reminder, Tag Wrangler, Tasks, Tasks Calendar, Wrapper, Templater
