refactor: navbar에 있는 atom을 제거하고 context를 추가하였습니다 #55
Conversation
| applicationNavbar: { id: number; title: string }[]; | ||
| className?: string; |
There was a problem hiding this comment.
ApplicationNavbarState 타입을 사용하는거 어떤가유
|
Profile log |
|
@2yunseong |
|
@JNU-econovation/econorecruitefe |
|
오호라 hydrateAtom이라.. |
| > | ||
| <ApplicationQuestion className="flex-[3_0_0]" /> | ||
| </ApplicationQuestionsContext.Provider> | ||
| </ApplicationNavbarContext.Provider> |
There was a problem hiding this comment.
혹시 provider를 app/application/page.tsx에 감싼 이유가 있을까요? 개인적으로 layout.tsx에 모두 넣어도 될 것 같다는 생각이 듭니다! 다른 페이지에서도 똑같이 provider를 만들게 될 텐데, 여기저기 분산되어 있으면 불편할 수 있을 것 같다는 생각이 들었습니다! 물론 다른 주소(다른 라우터)와 공유되지 않고 독립적이라면 큰 불편함은 없을 것 같긴 합니다!
There was a problem hiding this comment.
사실 사용하는 domain?이라고 해야할까요? 그런건 저기밖에 없었어요! ㅋㅋㅋㅋ
There was a problem hiding this comment.
고생하셨습니다!
https://jotai.org/docs/guides/nextjs
공식문서를 읽고 이해한 점입니다.
atomWithHash와atom의 가장 큰 차이는 hydration 시 atom 값이 동기화 되는지 여부.atom은 ssr 시 값이 동기화 되지 않아서 사용 시 어려움이 있다.atomWithHash는 ssr 시 값이 동기화되기 때문에atom의 문제점을 해결할 수 있다!
이렇게 이해했는데요! 사실 atom + ssr 이 어떤 문제가 있는지 정확히 몰라서 atomWithHash를 사용할 때의 장점이 크게 와닿지 않는 것 같습니다..!
추가적으로 저도 context보단 상태관리 라이브러리를 사용하는 것이 성능측면에서 좋다고 생각합니다.
|
atom + ssr의 문제점은, 서버에서의 상태와 브라우저의 상태가 다를 수 있다는 것이에요. 이런 문제가 있기 때문에 hydration, dehydration, rehydration이 있는 것이고, 이로 상태를 다시한번 더 동기화를 하고 있어요. |
|
오 서버 상태와 클라이언트 상태가 다른 게 문제라면 꼭 수정할 필요가 있다고 생각합니다! context와 jotai의 기능을 사용하는 것 중에선 jotai의 기능을 사용하는 게 좋다고 생각합니다. |
요 기능 사용해보는 거 좋은 것 같아요! |
|
@JNU-econovation/econorecruitefe |
오.. 이런것도 있네요 괜찮은 것 같기두?? |
|
와우 정말 좋네요! tanstack-query로 받은 데이터를 전역적으로 사용할 수 있다는게 새롭네요! 저는 긍정적인 생각을 가지고 있습니다. |
|
이제 다만 걱정인 것은, server 상태인지, client상태인지 헷갈릴꺼 같아서 걱정 됩니다. |
|
@JNU-econovation/econorecruitefe |
주요 변경사항
리뷰어에게...
관련 이슈