상태관리가 진짜 필요한가? 전역에서 상태관리를 할 경우가 진짜 생길까? - 생각해 봐야하는 문제
- 요즘 트랜드 - 상태관리를 할일이 별로 없다.
- 상태관리 = api를 가져와서 보관을 하는 것. -> react query를 쓰면 상태관리를 할 일이 별로 없다. (대신 해줌)
- 요즘 reduce를 많이 안쓴다.
- 상태관리를 어떻게 하는지에 대해서 배우는 것임.
- 대체 가능, recoil은 쓰지 말아라. -> 문제가 있다 생각. 프로젝트가 빠르게 성장하고 있지 않다. ssr이 필요한 경우 next를 사용하는데, 누수 문제가 있었다.
- reduce, zustand, …
- context api - 굳이? 성능 이슈가 생길 수 있다.
nextjs
page router, app router
page - component
강사님 자료
react와 redux?
mvc = model(데이터) vue controller
문제가 있었다. → 하나 바꾸면, 다른게 바뀌고..
개발자가 수정해야할 것이 너무 많았다. controller에 너무 의존했다는 이야기
⇒ 그래서 react를 내놨다.
rest api - 정적, 요청보내면 응답만 함.
비동기 - 동적
동적, 정적 두가지가 나오면서 rest api는 문제가 생겼다.
멱등성이 완전 깨졌다.
- 데이터가 바뀔 때마다 DOM 요소를 수정하는 것은 멱등성을 해친다.
dom 요소가 바뀔 때마다, ui그려냄 -> 이건 멱등성을 보장.
프로젝트 관련
- 커밋 내역 잘 적기
- 면접관이 코드를 다 볼 수 없다.
- rebase 잘활용해서 , 남들에게 보여주는 일기 적기
- 포트폴리오용 - pr 잘 적어야한다. & 격식
- pr 템플릿
- pr에 코멘트 적기
- 나를 힘들게 하지 않을 사람을 뽑을 것임.
- 회고
- 블로그에 적으면 좋다.
- 하면서, 어떤 것을 고민 했는지 내용을 적으면 좋다.
배민 - pr하나가, 한 커밋
-> 커밋 하나가 굉장히 의미가 있어야한다.
깃헙 플로우 - 기능이 마무리 되지 않더라도 머지
main은 rebase하면 안된다. - 뒤에 커밋 id가 바껴서 문제가 생긴다.