#상태관리

리액트 상태관리, 어떻게 하고 계신가요?

안녕하세요, 주니어 프론트엔드 개발자입니다. 현재 저는 어드민 프로젝트를 리액트로 만드는 작업을 하고 있습니다. 프로젝트 규모가 꽤 크다보니, 상태관리에 대해 많은 고민을 하고 있어요. 그 동안 내가 알던 리액트가 맞나 싶을 정도로 상태에 대해 다시 생각해보고 있습니다. 처음에는 상태관리 라이브러리 없이 작업을 했습니다. 나름대로 기획서를 보고 상태를 저마다의 컴포넌트에 넣어 사용했어요. 그런데 진행하다보니 다른 곳에서도 해당 상태를 사용해야하는 일이 빈번하게 발생해서, 수정하는 시간이 길어질 때가 많았습니다. 그래서 결국 전역 상태관리 라이브러리(zustand)를 사용하게 됐어요. 막상 사용해보니 정말 좋았습니다. 제가 생각한 장점은 다음과 같아요. - 사용할 컴포넌트에서 바로 사용이 가능하다. - 스토어에서 뽑아 사용하다보니 데이터 동기화가 비교적 쉬웠어요. - 스토어별로 파일을 분리하고, 해당 로직만 담겨 있어 파악하기가 쉽다. - 며칠 뒤에 봐도 이어서 작업하기가 좋았습니다. - 이전에는 상태들이 어느 컴포넌트에서 쓰이는지 헷갈릴 때가 많았어요. - 컴포넌트는 뷰 컴포넌트로, 비즈니스 로직이 스토어에 담겨 있어서 좋았어요. 제 짧은 경험에 느낀 장점들로 계속 사용하고는 있지만 자꾸 의문이 듭니다. 거의 모든 상태들을 스토어에 담아 사용하다보니 '전역' 라이브러리의 역할에 맞지 않다고 생각이 들어요. 페이지 간에 공유하는 상태는 없다보니 context api도 고려해봤지만, zustand와 달리 하위 컴포넌트가 리렌더링이 되고, 해당 api는 다크 모드같은 기능에 쓰고, 러닝커브가 비교적 적은 zustand를 선택했습니다. 결론은, 여러분은 상태관리를 어떻게 하고 계신지 궁금합니다. 어떠한 기준이 있는지, 전역 상태관리 라이브러리는 어떤 경우에 쓰는지 등 제가 경험이 적고 혼자 프론트 개발을 하다보니 모든 의견 하나하나가 소중합니다. 리액트 상태관리에 대한 선생님들의 고견을 부탁드립니다.

data fetching은 어디서 하는 게 좋은 것일까요?

안녕하세요. 저는 프론트엔드 개발자가 되기 위해 공부중인 취준생입니다. 피드백을 적극 환영하기에 많은 피드백 혹은 의견을 많이 남겨주시면 감사하겠습니다. 저는 데이터 페칭을 어디서 하는 게 좋을지 고민 중이라 글을 남깁니다. 아래와 같이 3개로 글을 구성해봤습니다. 1. 현재 개발상황 2. 현재 저의 데이터 페칭 위치 3. 궁금한 점 1. 현재 개발상황 저는 개인 프로젝트로 Next.js와 React Query를 사용하여 개발하고 있습니다. 현재 Next.js의 App Router를 사용 중이며, 프로젝트 구조는 아래와 같습니다. app: page.tsx, layout.tsx components: 최소 2번 반복 사용되는 재사용 가능한 컴포넌트 container: 일반적인 컴포넌트 (조합 등) hook, service 등 2. 현재 저의 데이터 페칭 위치 현재 데이터 페칭은 최상단의 app -> page.tsx에서 수행하고 있으며, 자식 컴포넌트에는 데이터를 props로 전달하고 있습니다. 이러한 이유는 prop drilling이 발생하더라도 데이터 페칭을 한 곳에서 처리하면 코드 이해가 쉬울 것 같아서입니다. 현재로서는 전역 상태 라이브러리를 사용하지 않아 최대 4단계까지 prop drilling이 발생하고 있지만, 전역 상태 라이브러리를 도입하면 prop drilling 문제는 해결될 것으로 생각하고 있습니다. 추가적으로 현재 이렇게 구현하면서 data fetch할때 필요한 query값들도 최상단에서 관리해야하는 불편함이 있었습니다. -> 최상단에서 관리해야 하는 상태값이 늘어남 3. 궁금한 점 3-1. 아래의 2가지 data fetching 방법 중 어느것이 적절한지? 합리적인지 의견이 궁금합니다. - 최상단에서 Fetching - 장점 : 한 곳에서 Fetching하기에 코드 일관성, 가독성, 코드를 이해하는데 좋다고 생각 - 단점 : prop drilling, 추가적인 전역 상태 관리 해야한다고 생각 - 필요한 컴포넌트에서 Fetching - 장점 : 필요한 컴포넌트에서 fetching 하기에 prop driling과 같은 불필요한 코드 작성 할 필요 x - 단점 : 어떤 컴포넌트에서 fetching 했는지 파악하기 힘들어짐 3-2. 현재 최상단에서 모든 데이터 페칭을 하고 props로 전달하는 방식 vs 필요한 컴포넌트에서 데이터 페칭을 하는 두 가지 방식 중 어느 것이 더 많이 사용되는 패턴인지 궁금합니다. 3-3. React Query는 서버 상태 관리, 캐싱, Optimistic Update와 같은 기능을 위해 도입했습니다. 그러나 prop drilling을 해결하기 위해 React Query에서 가져온 서버 데이터를 전역 상태 라이브러리에 담게 되면 서버와 클라이언트 상태를 구분하는 의미가 없어지는 것 같다는 생각이 듭니다. 제가 잘못 사용하고 있는것인지 궁금합니다.

react,vue 에서의 빈번한 store 사용

1. 어떤 프로젝트는 전역상태관리를 많이 사용하돼, 특정 페이지에서만 사용하지만, 상태관리가 잘 되어있는 프로젝트가 있고, ( 전역상태에 대한 사용 기준보단, 상태관리 자체에 더 집중함 ) 2. 또 어떤 프로젝트는 전역상태관리 store 를 정말 필요성이 있거나, 각 다른 컴퍼넌트나 페이지에서 공통으로 사용할 state 를 사용할때만, 전역관리 store 를 사용하는 프로젝트가 있습니다. ( 전역상태 사용 기준이 엄격함) 이번에 리드개발을 맡게되어 store 사용에 대한 정의가 필요한데, 어떤 것이 더 좋을까요? 각 어 떤 장단점이 있고, 또 어떤 기준으로 전역상태로 관리할지, 지역상태로 관리할지 정하시는지 경험을 듣고 싶습니다. 추가적으로 , 제 기준에선 zustand 가 정말 사용하기에 편하더라구요, 누구든 쉽게 터득할수 있고.. 프로덕션에서 RTK 와 zustand 각각 어떤 장단점이 있을까요?

Next 13과 react 18 서버 컴포넌트 관련 질문 (질문이 좀 길어요)

안녕하세요, 요즘 next 13과 react 18 서버 컴포넌트에 대해서 본격적으로 파고 있는데 궁금한 점들이 여러가지 떠올라서 글 올립니다. 1. data fetching 방식의 변경 우선 기존에는 동적인 data fetching의 경우, getServersideProps를 통해서 페이지의 root에 전달해주고는 방식이 일반적이었는데 서버에서만 돌아가는 서버 컴포넌트가 나오면서 data fetching을 컴포넌트 단위로 할 수 있게되면, 기존에 사용하던 getServersideProps 같은 유틸 함수들은 사라지는건가요? 기존에는 정적 데이터면 getStaticProps, 동적 데이터면 getServersideProps, 유저 상호작용이 필요한 데이터면 client side useEffect를 많이 사용했는데 next 13부터는 이게 뭔가 뒤섞이는 것 같아서 혼란스럽네요. next 13을 위한 data fetching 패턴이나 방법론이 있나요? 2. 기존에 사용하던 상태 관리 프레임워크의 변화 위와 어느정도 연결되는 이야기입니다. 기존에 react-query를 많이 사용했는데 next 13부터 컴포넌트 레벨로 데이터를 요청할 수 있고 또 next 차원에서 요청 중복 제거를 지원하게되면 react-query 처럼 서버 상태관리와 캐싱을 강점으로 내세우는 프레임워크의 역할을 어떻게 되는건가요? 서버 상태를 컴포넌트 레벨에서 가져올 수 있다고 해도, 여전히 전역 상태 관리가 필요할 것 같은데 recoil, redux, zustand 같은 상태 관리 프레임워크도 계속 쓰게되는 것일까요? 계속 쓰게 된다고 하면 서버 컴포넌트와의 호환성은 어떻게 되는건가요? 만약 전역 상태 관리를 써야하는 컴포넌트라면 서버 컴포넌트가 될 수 없는 것인가요? 3. 서버 구성의 변경 다른 곳은 모르겠지만, 저는 next 백엔드를 단순히 요청을 전달하는 용도로만 쓰고 실제로 중요한 로직은 다른 백엔드 서버에서 처리하는 구조를 가지고 있었습니다. 하지만, next 13을 보니 서버 컴포넌트에서 DB 연결을 직접해서 데이터를 가져오는 예시들도 있더군요. 사이드 프로젝트라면 모르겠지만, 실 서비스에서도 서버 컴포넌트 - DB 직접 연결 이라는 구조가 성립할 수 있는건가요? 기존에 데이터를 취합하고 내려주던 백엔드 서버의 역할이 생략되는거라고 생각해도 되는건가요? 4. 왜 다시 20년 전으로 돌아가는거죠 제가 20년 동안 개발한 것은 아니지만, 예전에는 웹페이지를 서버에서 완전히 로드해서 내려주는 형태를 가지고 있었다고 배웠습니다. 그러다가 개개인의 기기가 스펙이 좋아지면서 서버 부하를 줄이고 클라이언트 쪽에서 역할을 분담하는 방식이 떴다고 들었어요. react도 처음에는 이런 프레임워크로 나왔다고 알고 있습니다. 그러다가 next, remix 같은 프레임워크들이 서버사이드 렌더링을 적극적으로 장려하면서 다시 회귀하고 있다고 들었습니다. 최근에는 react 마저 서버 컴포넌트를 발표했잖아요. 왜 이제와서 다시 서버 쪽에서 페이지를 로드하는 방식을 추진하고 있는건가요? 질문을 적고보니 좀 길어졌는데, 서핑을 좀 해봐도 마땅히 도움이되는 글이 별로 없어서 현직자들은 어떻게 생각하시는지 의견을 얻고자 질문 올립니다!

토큰 관리, 로그인 유지를 현업에서는 어떻게 진행하는지 궁금합니다

안녕하세요 토이프로젝트로 인증/ 인가 파트를 맡게되었습니다 이전의 프로젝트에서는 로컬스토리지과 전역 상태 관리 라이브러리의 persist를 활용하여 토큰과 로그인상태를 로컬스토리지에 저장하여 진행하였습니다 하지만 이번에 새롭게 진행하는 프로젝트를 위해 다양한 웹사이트를 개발자도구로 참고하였지만 토큰이나 isLogined와 같이 로그인 여부 상태를 로컬, 세션 스토리지에서 관리하는 사이트를 확인할 수 없었고, 검색을 통해 보안을 위해 Http Only 쿠키를 통해 액세스 토큰과 리프레시 토큰을 관리하는 방법이 일반적이란것을 알 수 있었습니다 이러한 방법에서 몇 가지 궁금증이 생겨 질문을 드리고 싶습니다 1. 현업에서는 어떠한 방식으로 토큰을 관리하고 로그인 상태를 유지하나요? 2. 만약 http only 쿠키를 사용하게 된다면, 쿠키에 저장된 토큰을 클라이언트에서 조작할 수 없으니, 매번 페이지를 렌더링 할 때마다 토큰이 유효한지 api 호출을 통해서 로그인 상태를 유지해야하는걸까요? (api를 통해 토큰이 유효하다면 로그인 유지, 아니라면 로그인 페이지 리다이렉션) 3. http only 쿠키 외에 인증 / 인가를 위해서 클라이언트 단에서 보안적으로 신경써야하는 부분은 어떠한것이 있을까요? 가장 기본적이지만 가장 어려운 인증/인가 부분 현업 선배님들께서는 어떻게 진행하시는지 답변해주시면 감사하겠습니다

nextjs 전역 상태관리 질문

안녕하세요 nextjs(App router 사용)로 프로젝트를 진행하고 있는데, 전역상태를 정의하기 위해서 zustand를 사용하려고 하고 생각중입니다. 전역 상태를 정의하기 위해서는 1. 가장 root가 되는 layout.tsx에 provider를 불러와 감싸주어, 전역적으로 참조할 수 있도록 하는 것 2. persist middleware을 사용해서 LocalStorage에 저장하는 방식으로 상태를 관리하는 것 이 정도 두 가지가 있는 것 같은데, 질문은 1. 만약 1번 방법을 사용한다면 client component로 선언한 custom provider로 자식 컴포넌트를 감싸게 될텐데, 그러면 상태가 변경됨에 따라 하위 컴포넌트들(server, client 상관없이)이 모두 리렌더링 되는 것인가요? 만약 그렇게 된다면 SSR의 의미가 사라지는 것 아닌가요? 2. 일반적으로 nextjs에서는 전역 상태를 어떤 식으로 관리하나요? 입니다. 감사합니다!

신입 프론트 개발자 9개월차 이직조언 부탁드려요!

안녕하세요! 프론트 개발자로 9개월째 일하고 있는 신입 개발자 입니다! 아직 1년도 되지않은 이시점에서 자꾸 이직 생각이 드는데... 이런 상황에서 이직이 맞는걸지 아니면 좀더 회사를 다녀보는게 좋을지 조언을 구하고 싶습니다. 제가 처음 입사했을당시, 리엑트를 사용하는 신규 프로젝트를 하게 되었습니다. 신규 프로젝트인데 생각보다 규모가 크고 일정이 빠듯했기에 개발을 함에 있어서 다른 무엇보다 "속도와 일단 동작되도록" 에 가장 큰 초점을 두고 일했습니다. 당연히 일정을 맞추는게 가장 급한 일이었기에 코드리뷰같은건 꿈도 못꿨습니다. 테스트코드도 없구요. redux를 사용했지만, 제대로 상태관리를 하면서 사용하기보단, 그냥 거의 모든 상태를 useState로 관리하면서 props drilling이 생기는걸 지금은 당장 급하니 나중에 생각해보자고 하시더라구요. Style같은 경우도 일단 빨리해야하니 inline으로 다 작성하자고 하시더라구요. 이런 방식으로 개발을 빠르게 진행하고 프로젝트 배포를 했습니다. 물론 지금도 계속 배포 이후 버그를 수정중인데, 버그가많아 리팩토링은 계속 미뤄지고 있습니다. 이후 저는 리엑트가 아닌 플러터 프로젝트를 하게 되었습니다. 물론 처음 배우는 거라 혼자 독학으로 틈틈히 회사다니면서 공부했고 지금 기본적으로 레이아웃 잡고 api붙이고 하는 작업들을 하게되어 웹이 아닌, 크로스플랫폼앱 개발을 3개월째 하고있습니다. 리엑트할때는 사수(팀장)가 있지만 너무 바빠서 그냥 혼자 알아서 다 했던거같습니다. 가끔 여쭈어 보아도 그냥 혼자 해보라고만 하시더라구요. 그래서 고민을 더 해보고 이런이런 이유로 이렇게 코드를 짜서 이런 결과가 도출되길 바랬는데 저런 결과가 나왔다 근데 아무리생각해도 이런 논리가 제생각엔 맞는거같은데 어디서 문제일까요? 라고 물었지만 돌아오는 대답은 그냥 알아서 잘 해봐라 였습니다.. 그래서 그냥 6개월동안 거의 구글과 gpt한테 물어보면서 일을 했습니다! 다행히 앱개발에는 다른 사수분이 새로 들어오셔서 나름 잘 알려주시고 있긴합니다. 이런 상황에서 이직을 고민하게 된 이유는 먼저 개발적인 부분에서 - 코드리뷰 및 피드백 X - 상태관리 X - 디자인시스템 적용 체계 X - 코드컨벤션 X - git branch 분리 X (only main) - 사수(팀장) 있지만 바빠서 자기일만 함 (다들 혼자 일함) - 웹개발자로 취업해서 리엑트도 아직 숙달되지안은 상태에서 갑자기 플러터를 하게되니 이도저도 아닌 경력이 되버릴까봐 걱정됨 (물론 플러터 배우는게 재밌긴 함) 이런 점들이 있습니다. 이외에 비개발적인 부분의 이유도 좀 있지만 그냥 개발적인 부분만 고민했을때 지금 회사가 기술적이나 그런 부분이 발전에 도움이 될까 하는 생각이 듭니다 ㅠㅠ 그리고 제가 9개월차로 리엑트 6개월 플러터 3개월 프로젝트를 진행했는데, 타회사로 이직하기에도 너무 애매하게 일을 해본거같아 그런점들이 고민됩니다.ㅠㅠ 그리고 그 흔한 상태관리, 스타일라이브러리도 못다뤘기에 이력서에 어떤식으로 써서 준비해야할지도 잘 모르겠고 고민만 늘어가고 있습니다.. ++)) 추가질문! 회사프로젝트는 private 레포인데 이력서에 깃헙주소를 넣을수는 없을거같은데 그럼 이력서에 회사프로젝트 내용은 어떤식으로 정리하면 좋을까요?? 긴글 읽어주셔서 감사합니다 객관적인 조언 부탁드립니다!! 감사합니다.

Next 서버 컴포넌트와 전역 상태관리

안녕하세요. Next15에서 서버 컴포넌트를 적극적으로 도입하여 프로덕트를 개발하고 있는데, 고민이 되는 부분이 있어 여러 분들의 도움을 얻고자 질문을 남깁니다. 서버 컴포넌트에서 받아온 데이터와 클라이언트 컴포넌트에서 사용하는 zustand가 적절히 사용되고 있는지 고민이 듭니다. 현재 GET 요청의 경우 각각의 서버 컴포넌트에서 fetch를 통해 진행하고, 해당 데이터를 자식 클라이언트 컴포넌트에서 사용할 경우 props로 내려 사용하고 있는데, 이때, 드릴링이 심해질 경우 zustand와 같은 전역 상태관리 라이브러리를 함께 사용하려고 합니다. 예를 들어, 서버 컴포넌트의 첫 번째 자식인 클라이언트 컴포넌트에서 zustand를 사용하고, 이후 자식 클라이언트 컴포넌트에서는 zustand를 통해 상태관리 할 때 자식인 클라이언트 컴포넌트의 업데이트가 진행되는 부분에서 try/catch를 통해 요청을 보내고, router.refresh()를 통해 서버 컴포넌트에서 데이터를 새로 받아옵니다. 이후 클라이언트 컴포넌트에서는 useEffect로 서버 컴포넌트에서 props로 받아온 데이터가 바뀌는 것을 감지하고, 해당 props를 zustand에서 사용하는 데이터로 업데이트하려고 하는데 문제가 될만한 점이 있을까요? 이와 관련된 링크나 답변이 있으시다면 감사히 받겠습니다!

Next.js로 프로젝트 중인데, 팀원과 의견조율이 잘 안돼서 도움 부탁드립니다.

안녕하세요, 저는 백엔드 개발자로 일한지 이제 2년차가 된 개발자입니다. 사이드프로젝트에서는 프론트 개발을 하고 있고 현재 Next.js를 사용하고 있습니다. 백엔드팀도 따로 있어서 Next.js의 API routes는 BFF같은 느낌으로 사용하고 있습니다. [Next pages] <-> [Next API] <-> [백엔드 서버] 현재 상황은 유저의 로그인정보를 어떻게 관리하냐로 이야기를 하고 있습니다. 1. 마이페이지 -> 프로필 수정 페이지 2. 로그인 -> 메인페이지 이렇게 유저의 프로필 정보가 많이 쓰이다보니까 이걸 매번 GET해서 가져올까, 전역상태로 관리할까 이야기를 하는데 좀처럼 의견이 좁혀지지가 않는 상황이라 다른 분들의 의견을 여쭙고 싶습니다. (참고로 저희 둘 다 프론트 개발경험이 그리 많지 않습니다) A: 그냥 매번 GET하자.(넥스트 API 캐싱을 사용하자) - 전역상태관리보다 코드 복잡도가 줄어들 것 같다. - 넥스트의 API 최적화를 사용하는 게 더 Next스러운 방식같다. B: 전역 상태로 관리하자. - useEffect로 현재 모든 GET 요청을 하고 있기 때문에 윌업데이트에 변경이 일어나면 재렌더링이 일어남 - (하지만 컨텍스트 정보가 바뀌지 않으면 최초 렌더 이후 리렌더 되지 않음) - 캐싱한 데이터를 받아오더라도 결국 불필요한 api요청을 보내는 것이며 api요청을 보내는 것보다 전역 상태에서 가져다 쓰는 것이 더 바람직하지 않나 서로 비슷한 실력에 사람도 둘 밖에 없어서 결정을 내리기 힘들어서, 다른 분들의 의견을 좀 들어보고 싶습니다. 읽어주셔서 감사합니다.

react에서 복잡한 상태를 관리할때.. 한번에 관리? 분리해서 관리? (jotai, recoil, useState)

안녕하세요 react를 이용해서 복잡한 작성 페이지를 만들고있습니다. 아래의 타입은 예시입니다. type payload = { name: string; message: string; type: string; url: { pc: string; mobile: string; }; contents: { images: { url: string; name: string; }[]; buttons: { name: string; url: string; }[]; }; conditions: { ... }, .... }; 위처럼 복잡한 데이터를 서버로 보내줘야해서 데이터를 관리해야하는데 현재는 페이지내에 구조가 복잡하고 컴포넌트도 매우많아 props drilling이 너무 심해질거같아서 recoil, jotai와 같은 상태관리 라이브러리를 이용해서 작업을 진행하고있습니다. 이러한 상황에서 관리하는 데이터를 한객체에 모아서 관리하는게 좋은지 아니면 const nameAtom = atom(''); const messageAtom = atom(''); const typeAtom = atom(''); const urlAtom = atom({ pc: '', mobile: ''}); .... 처럼 일일히 쪼개서 관리하는게 맞는 방향인지 모르겠어서 질문드립니다 ! (사수가없어서 물어볼곳이없어요...) 현재는 아래와같이 쪼개서 작업한뒤 submit시에 합쳐주는 방식으로 구현해놓았는데 atom 갯수가 20개 정도 되버리니까 너무 복잡해보여서 이게맞나... 싶어서 질문드리게되었습니다.

react에서 state를 잘 관리하는 방법 질문 드립니다

안녕하세요 왕킹왕짱짱초보 프론트 개발자입니다 현재 react와 recoil을 사용하여 프로젝트를 개발중입니다 구조는 간단하게 도메인별로 (ex pages 디렉토리 하위 login 디렉토리 하위 action, model, component 이런식으로 구조를 잡아뒀습니다 다른 도메인들도 똑같이 잡아서 사용하고있습니다 서론은 저는 recoil을 그저 로그인 데이터나 다국어 정보등 localstorage와 연관된 정보나 말 그대로 프로젝트 전체 범위에 영향을 끼치는 상태들만 관리하는 용도로 사용하고있습니다 그런데 프로젝트를 진행하다보니 각 도메인별로 컴포넌트 개수가 많아지고 특히 Modal을 사용하거나 api호출 시 isLoading과 같은 상탯값을 다룰때 이게 상태가 많아지고 넘기는 값이 많아지니까 제가 만든 코드를 제가 구분하기 힘든 지경에 이르러버렸습니다... 본론은 도메인별로 api, model, compnent를 관리할때 recoil이나 redux같은 전역 상태도 각 domain별로 atoms 디렉토리나 store 디렉토리로 관리해도 괜찮을까요?? 전역 상태 관리 남용이나 오용은 아닌지 걱정도 되고.. 잘 몰라서 해도 되는지 확신이 안 서네요.. 🙇

개발 공부를 어떻게 하는게 좋을까요? (feat. 프로젝트)

얼마 전 Next.js로 개인 프로젝트를 진행했습니다. 그런데 프로젝트를 진행해보며 제가 어떤 방식으로 개발 공부 뱡향성을 잡아야하는지 혼란스러워 질문드립니다 ,, 🙏 처음 Next.js 쓸 때는 복붙 ,, 같은 기능도 복붙해서 파일 여러 개 만들기를 하고, 서버 컴포넌트와 클라이언트 컴포넌트에 대해 잘 알지 못한채로 프로젝트를 했었습니다. (+ 상태관리나 ,, 이런 것도 아예 모르고 개발했었습니다 ,,) 이번에 제대로 공부해서 기능을 구현해보고 싶어 다시 시작해서 완성했습니다. 그런데 제가 작성한 코드를 다 이해하며 작성했지만, **제가 작성한 코드가 좋은 코드인지? 에 대한 의문이 생겼습니다.** 그래서 팀 프로젝트도 참여해보며 같은 프론트 팀원 분의 코드를 확인해보며 좋아보이는 부분은 참고도 했지만, 이 방법도 한계가 있었습니다. 더 잘해보고 싶어 빨리 보여져야하는 이미지는 이미지를 미리 로드한다거나, next/image로 이미지 최적화를 하고 최대한 코드 중복을 줄이고자 공통 컴포넌트들을 만들기 위해 노력하긴 했었습니다. (나중에 스토리북 이라는 라이브러리를 알게되어 이걸 사용해보지 못한게 아쉽긴 했습니다.) 그래도 많이 부족한거 같아 어떻게 더 나은 개발을 해야할지 잘 모르겠습니다 ,, 첫 프로젝트에서는 부트스트랩 외에는 사용해보지 않아 이번에 제대로 다양한 기술을 써보고자 시도도 해보았습니다. (> 서버 상태 관리를 위해 tansack query도 사용해보고 클라이언트 상태 관리를 위해 recoil을 사용하고, 스타일링에는 css in js가 궁금해 styled components, 직접 어느정도 깔끔한 디자인을 하고싶어 피그마 툴을 이용해보았습니다. 소셜 로그인도 넣어보고 몽고 db 사용하며 데이터베이스도 연결해보았는데 ,, 막상 완성하고 나니 제가 많이 부족하다는 생각이 들었습니다.) 🤔 제가 작성한 코드가 좋은 코드인지 ,, 더 나은 성능을 위해 어떤 개발을 하면 좋은지와 같은 부분은 제가 어떻게 학습하는게 가장 좋은 방법일까요? 또한 어떤 것을 더 배워서 적용해보는게 좋을까요? ,, (제가 생각했을 때 프로젝트를 완성은 했지만, 제 프로젝트의 매력적인 점이 없는거 같아 너무 아쉬운거 같습니다.)

Next 14 전역 상태 관리 질문

커뮤니티 개발할 때 리스트같은 경우는 보통 useContext 로 전역 관리 하나요? 그래서 뒤로가기나 그럴 때 기존 상태 보여주도록 하나요?..

React 상태관리질문

학원에서 프로젝트를 진행중인데 기능이많아 상태관리가 많아요. React useContext와 Redux중 어떤상태관리를 사용하는게 유리할까요?? 그리고 현업에서는 어떤방법을 택하는지 궁금합니다

[Flutter] 실무에서 flutter 상태관리는 어떤걸 사용하나요?

찾아보니까 패키지가 엄청나게 많더라구요 provider, riverpod, getx, get_it..... 졸업작품 개발 중 인터넷 상태 앱 전역 검사를 구현하다가, getx를 접하게 되어서 상태관리가 중요하고, 코드를 효율적으로 짤 수 있구나를 깨닫고 공부해보려고 합니다 이 주제 아니어도 flutter와 그 외 실무에 관해서도 조언 받고싶습니다!

react 전역 상태 관리 도구 사용

안녕하세요~! 최근에 프론트엔드를 배우게 되어서 여쭤봅니다.. react 를 사용하면서 props drilling 을 겪고, 복잡한 코드가 되어 가는 중입니다. 궁금한 점은 zustand를 전역 상태 관리 도구로 사용하고 있는데 zustand를 어떻게 사용해야 잘 사용하는 것 일까요? 렌더링을 조금 깔끔하게 하고 싶어서 문의드립니다. 상황에 따라 다르겠지만 zustand를 많이 써서 state를 store 형태로 보관해서 사용하는게 좋을까요? 전문가들의 고견 부탁드립니다.(_ _)

리엑트 네이티브에서 클라이언트, 서버 상태 관리를 같이 관리하시나요 따로 관리하시나요?

리엑트로 작업을 진행할 때 클라이언트와 서버 상태 관리를 각각 따로 하다보니 관심사의 분리로 관리하기가 편했어서 이번에 리엑트 네이티브에도 적용하려고 하는데 고민이 있습니다. 리엑트 네이티브에서 상태관리를 보통 어떻게 하시는지 궁금합니다. 혹시 제가 하고자 하는게 맞는건지도 고민이 됩니다.

디자인 패턴이 필요할 때는 언제인가요?

안녕하세요. 1년 조금 넘게 프론트엔드 직무로 개발 중인 개발자입니다. 현재 회사에서 어드민 페이지를 개발하고 있습니다. 저 혼자 프론트를 맡아서 개발하다보니, 시행착오가 정말 많습니다. 특히 이번 프로젝트는 사용자와의 상호작용이 많아서 코드를 갈아엎은 일이 꽤 있었습니다..ㅎㅎ 그래서 제 고민은요! 디자인 패턴이 필요한 때인가 싶습니다. 저는 기존에 만들어진 것을 유지보수하거나, 기능을 붙이기 보다는 바닥부터 새로 만드는 프로젝트를 맡아서 개발을 했어요. 그럴 때마다 드는 생각이 자꾸 첫 단추를 잘못 끼는 느낌이 듭니다. 경험이 부족해서 일까요? 기간 내에 개발을 완료하고 싶은 욕심이 있습니다. 처음엔 state를 2~3개 정도 내려주는건 괜찮다 생각해서 상태관리 라이브러리 없이 최상단 컴포넌트에서 관리하고, 컴포넌트를 객체로 관리해서 사용자가 클릭할 때마다 스위칭 되도록 만들었어요. 그런데 이런 것들이 계속해서 추가되고 관련된 상태와 상호작용들이 많아지다보니, 결국 상태관리 라이브러리를 사용하게 되었어요. 이렇게 바뀌다보니 시간도 오래걸리는 느낌이 들고, 더 나아가 좋은 구조에 대해서도 고민이 되고..그걸 위한 게 디자인 패턴인가? 생각이 들었습니다. 그래도 나름 시행착오를 많이 겪어서 전보다는 문제 해결이 빨라진 느낌이 있지만, 더 성장하기 위해서 키워드를 얻고 그 방향으로 나아가고 싶어요. 뭔가 제가 모르는 것을 모르는 듯한 느낌이 듭니다. 따라서 프로젝트를 시작할 때 어떤 것들을 먼저 고민해야할지, 그리고 디자인 패턴이 필요하다고 느꼈을 때는 언제인지와 같은 전략, 경험이나 조언을 얻고 싶습니다.

부트캠프 최종발표 내용에 관해서

선생님들 안녕하세요. 부트캠프에서 셀프세차장 예약 앱을 주제로 약 두달여간의 개발을 진행했고, 3일 뒤에 최종발표만을 남겨두고 있습니다. 부트캠프 운영진 측에서 최종발표 내용으로 개발 주안점을 둔 부분을 주로 다뤘으면 좋겠다고 하셨습니다. 발표 내용을 미리 구성해봤는데, 선생님들께서 보시고 조언 좀 주시면 감사하겠습니다. 저희 팀 개발 스택은 다음과 같습니다. FE: React, Redux-thunk, React-query BE: Spring Boot, MySQL, Amazon S3 아래와 같이 발표 내용을 구성해 봤습니다. 1. 프론트엔드 a. 아토믹 패턴의 활용 - 기획단계에서부터 모든 컴포넌트들을 미리 설계해놓고 atom, molecule등의 레벨로 미리 나눠놨다. 덕분에 개발을 빠르게 진행할 수 있었고, 유저들에게 일관된 인터페이스를 제공한다. b. 예외처리 - 유저들에게 보다 친절한 에러를 제공하기 위해 백엔드와 협의하여 세부 에러코드들을 정의했다. 각 컴포넌트들을 에러 바운더리로 감싸 GET 요청이 실패한 경우에는 Fallback UI로 화면을 덮어줬다. 그리고 각 API들의 onError 콜백을 부여하여 Mutation 요청이 실패한 경우에는 alert로 알려준다. c. 상태관리 - props drilling 현상을 방지하기 위해 redux-thunk를 사용해 세차장 정보를 불러올 때마다 세차장 정보를 전역 상태로 관리하여 자식 컴포넌트로 넘겨주게 구성했다. 2. 백엔드 a. 예약 신뢰성 - 사용자가 요청한 예약이 운영 시간을 준수하고 중복 예약이 방지되도록 예약 검증을 철저히 하였다. b. 예외 처리 - 명확한 예외 처리 및 상태코드 할당 c. 권한 - 역할 기반 권한 관리, 사용자 인증 및 JWT 토큰 처리 여기까지입니다. 내용을 잘 구성했는지 모르겠습니다. 제가 경험해본 프로젝트 중 가장 규모가 큰지라 발표 내용이 부족하진 않은지 걱정이 많이 됩니다. 발표 평가위원이 주로 개발자라고 하셔서, 개발자의 시선으로 봤을 때 위 주제들이 어떠한지 고견을 듣고 싶습니다. 감사합니다.

react-hook-form 복잡한 form에서 궁금점이 있습니다 !

안녕하세요 현재 진행하는 프로젝트에서 form을 recoil로 관리하고있습니다. 이유는 form과 화면구성이 너무 복잡한 형태라 props drilling도 심하고 (부모에서 자식까지 5~7 depth) 관리해야하는 데이터가 많아 store에서 관리하고있습니다. react-hook-form이 복잡한 form에서 효율을 낸다고 해서 마이그레이션 해볼까 생각중인데 궁금점이 있어 작성합니다 ! 1. 이렇게 전역적으로 관리를 해야하는 복잡한 form에서도 좋은 효율을 내고 전역 상태관리 라이브러리보다 좋은 방향일까요?! (FormProvider 를 사용) 2. form에서는 input 필드만이 아닌, tab클릭, 드랍다운 클릭, 체크박스 클릭, 이미지 업로드, 라디오 클릭 등등 이러한 경우가 많은데 react-hook-form 을 사용해도 좋은 방향인가요?! 어떨때 react-hook-form을 사용하면 좋은지 궁금합니다 !

성과를 수치로 작성하는게 어려워요

안녕하세요, 현재 퍼블리셔로 일하고 있습니다. 업무를 진행하며 이직 이력서를 작성 중인데, 성과를 수치로 나타내는 것이 어렵습니다. 대부분 과업 특성이 어떤 레이아웃 혹은 기능을 구현하는 수준에서 결과물이 도출했다 라는 것인데요 "성과를 수치로 작성하는 것이 참으로 어렵습니다." 예를 들어 x%에서 xy%로 시간 단축/혹은 고객확보 이런식으로요 제가 구현한 UI가 사용자/고객에게 어떤 불편함이 있었고 혹은 이전 대비 어떤 차이점이 있는지 확인하기가 어렵습니다. 저와 같은 고민에 있었거나/ 있는 분들은 어떻게 이런 이슈를 해결하셨나요? 저와 같은 경우, 관심있는 라이브러리/언어로 개인 포트폴리오로 어필을 해야할까요, 현재 회사에서 다음의 작업을 진행했고/하고 있습니다, : 회사 홈페이지, 웹&모바일 리뉴얼 및 JS인터렉션 기능 추가 : GSAP으로 서비스 가이드 애니메이션 구현 => GSAP을 회사에서 정해준게 아니라, 필요한 기능이 GSAP으로 할 수 있는거 같아, 진행함 : 리액트로, 채팅앱 UI 프론트 담당 - 비동기 통신, 상태관리를 제외한 채팅앱 UI 기능 구현(프론트 담당) > 비동기 통신, 상태관리 데이터 구조는 백엔드 개발자가 정리한 목업 데이터를 가져다 사용하다 보니 - 컴포넌트 기능 개발(ex) 아코디언, 체크박스 등등 ) 성과-> 수치에 대한 방법에 대해 의견있는 분 있을까요? P.S 1. 혹시 저와 같이 퍼블리셔인데 리액트 업무를 하시는 분들은 어떻게 진행한 리액트 작업/업무는 어떻게 어필을 하면 좋을까요? 2. 현재 리액트 코드는 (회사에서) 작업 중 인데, 리펙토링하게 된 계기와 이유 혹은 코드 정리하는 것으로 성과(수치)를 설명해야 할까요? 감사합니다

nextJS 에서 안전하게 token 처리하기

nextjs에서 nextAuth 쓰지않고 안전하게 token 처리하는 완벽한 예시가 있는지 알고싶습니다. 사이드 프로젝트중에 여러 시도를 해봤는데 정답을 못찾겠습니다. 일단 axios 인터셉트로 ssr이나 csr이나 모두 토큰을 헤더에 담아서 보내는 것을 목표로 하고 있습니다. 1. 상태관리 라이브러리를 사용한다. 당연히 ssr 환경에서는 불가하니 탈락 2. 그냥 쿠키를 사용한다 보안 문제가 있으니 탈락. 3. http only 쿠키를 사용한다. csr 환경에서 접근할 수 없으니 탈락. 대안으로 생각해본 방법들은 1. 모든 api를 server action을 랩핑해서 미들웨어처럼 사용하고 http only 쿠키 이용하기 2. 쿠키와 상태관리 모두 값을 넣어두고 두가지 다 관리하면서 서버와 클라이언트 컴포넌트에서 각각 제어하기 하지만 두가지 방법은 너무 번거롭고 버그 양산일 것 같습니다. 많은 분들께 여쭤봤을 때는 그냥 쿠키를 사용하고 보안은 어느정도 포기한다는데 다른 방법이 있을까요?

상태 관리 라이브러리 무엇을 선택해야할지 궁금합니다.

프론트엔드 부트캠프 수강 중인 학생입니다. 현재 팀 프로젝트를 들어가기전에 상태관리 라이브러리를 활용해서 간단한 redux(CRUD), zustand(CRUD)까지 구현 해봤습니다. 질문1) 팀플젝을 장점인 많은 zustand로 하려고 했으나 취업 합격자들, 취업어플 정보들을 봤을때 redux와 recoil이 많더라구요. 그래서 저도 redux, recoil을 한정해서 플젝을 해야할까요? 질문2) zustand로 플젝해도 회사 자격요건에 회사에서 redux를 쓴다던가 redux경험 우대사항이 적혀 있다던가 하면 불이익이 있을까요?

자신이 설계한 프로젝트에 문제가 있다고 생각했을 때

안녕하세요. 여러분!! 제가 개인 프로젝트를 진행하다가 한 가지 궁금한 점이 생겨서 이렇게 질문을 올립니다. 제목과 같이, 프로젝트를 위해 설계한 프로젝트에 결정적인 문제가 있을 경우 어떻게 해결하시는지 궁금합니다!! 이런 생각을 하게 된 이유가, 제가 개인 프로젝트를 하던 중, 이런 비슷한 문제가 있었습니다. 저의 경우, 제 프로젝트에 상태관리 라이브러리를 사용하지 않아도 된다는 판단을 했었는데, 나중에 다시 조사해보니, 그 프로젝트에 상태관리 라이브러리가 필요성에 대해 느껴, 상태관리 라이브러리를 추가하고 있어야 할 페이지가 없어서, 만들기도 하는 등, 여러 가지 일이 있었습니다. 제가 최근에 경험한 실무에서는 이런 부분이 있을 때, 기획팀과 협의하여, 페이지나 팝업을 추가하는 등 일이 있었는데, 혹시 다른 분들은, 정말로 돌이키기 힘들 정도로 프로젝트를 잘못 설계하여 고생하신 적이 있을지 궁금해서 여쭤봅니다!!

React 에서 token, refresh-token 을 전역 상태로 관리하려고 하는데 어떻게 구현하는게 좋을까요 ?

안녕하세요!! token, refresh token 에 대한 global 상태관리를 해야 합니다. 이정도 규모의 상태관리는 어떤 기능을 활용하는게 적당할까요 ? - redux (사용해본 경험이 있어서 편하긴 한데.. 고민이 됩니다) - recoil

리액트에서 상태관리로 Redux를 무조건 공부해야할까요?

안녕하세요 저는 풀스택 개발자이고 2년만에 다시 리액트를 공부하려고 합니다. 얼마전에 리액트 2023 로드맵을 봤는데요 (사진 첨부했습니다.) 해당 로드맵에서 언급된 상태관리중 어떤걸 공부해야할지 고민됩니다. 상태관리 - 추천: Recoil, Zustand, Context - 대안: Redux / Toolkit, Mobx 2년전에는 Redux는 상태관리에서 거의 필수라고 했던 것 같은데 로드맵에서는 Recoil, Zustand, Context를 추천하고 Redux는 대안이라고 언급하네요. 요즘 리액트를 공부하게되면 Redux는 굳이 공부할 필요 없을까요? Recoil을 공부해보려고 하는데 Redux도 같이 공부해야하는 고민됩니다. 긴글 읽어주셔서 감사합니다.

이런 상황에서의 zustand 활용에 대한 질문있습니다 !

안녕하새요 ! zustand를 이용해서 프로젝트를 진행중인데 새로운 기능을 추가해야되는 상황입니다… 한 페이지에서 5개의 입력폼이 담긴 카드에 정보를 입력받아 (각 카드마다 드랍다운,데이트피커,텍스트필드 등 종류 및 갯수도 상이합니다) submit을 해주어야하는데 현재 상태관리로 zustand를 사용하고있습니다 ! 이러할때 각 카드마다 하나의 스토어를 구성해서 submit시에 합쳐서 넘기는것이 나을지… 아니면, 하나의 스토어에서 전부 관리하는게 나을지… ( 이경우엔 각각 상태값과, action들이 너무 많을것같아서…) 혹시 이런 상황에서는 보통 어떻게 관리하는게 맞을까요..?!

Url to state or url and state

흰색 배경의 button group이 있고 각각의 button은 클릭할 시 url을 변경시킵니다. 또한 현재 선택된 button은 색상이 칠해집니다. 이러한 상황에서 useState를 통해서 button의 state를 관리하고 있었고, button을 클릭했을때 1. setState를 통해 button의 값을 변경함 2. router을 통해 url 경로를 변경함 이렇게 두가지 액션을 취했었습니다. 그 때 생겼던 궁금중은 어차피 url과 button은 mapping 할 수 있으니까, 버튼을 클릭하면 url만 변경시키고, url을 읽어서 button에 다시 값을 주면 기능적으로 똑같지 않나? 그러면 하나의 액션으로 기존의 두가지 액션을 대체할 수 있지 않나? 라고 생각했습니다. 그래서 조금 찾아보니까 url을 바꾸고 그 값을 통해 button의 상태 관리를 다시 하는건 즉각적인 반응이 아니고, 영상에서 봤던 것 처럼 url과 button state를 각각 바꾸는게 더 인터랙티브하다 라는 글을 읽었습니다. (신빙성이 있는 글은 아닙니다.) 실제로 이러한 이유 때문에 url만 바꾸고, 그 값을 받아와 button 값을 할당하는게 아니라, 두가지를 모두 동시에 바꾸는게 더 좋은 방법이 맞는건지 궁금합니다.

신입 개발자 취준 고민이 있습니다

안녕하세요 신입 개발자로 취업을 하고싶은 준비생입니다. 부트캠프 수료한 지가 곧 있으면 1년이 다 되어가서 얼른 취업을 해야하지만 서류에서 광탈을 하는 상황입니다. 혼자서 생각하기에는 좀 고민되는게 있어서 경험이 많으신 분들에게 질문을 드리고 싶어서 글을 작성하게 되었습니다. 기존 포트폴리오는 자바스크립트,리액트 nodejs을 사용한 프론트, 백엔드를 둘다 다룬 프로젝트로 팀플 1개개인 프로젝트가 1개가 있고 구직기간 중 학습한 것을 바탕으로 만든 플러터 앱 프로젝트로 총3개가 있습니다. 취업을 위해 기존 프로젝트를 보완하거나 기존 스택을 이용하고 좀더 발전된 코드로 새로운 프로젝트를 추가하는 노력을 하는게 나을까요? (예를 들어서 상태관리 폴더 구조 관심사 분리 데이터베이스 설계 등을 기존 프로젝트보다 레벨업해서 새로 프로젝트 만들기) 아니면 취업을 위해 다시 한번 6개월 정도의 부트캠프를 다니는 것은 좋은 선택이 아닌걸까요? 찾아본 부트캠프로는 자바 풀스택 부트캠프 (지금까지 자바스크립트 기반으로 공부를 했기 때문에 자바까지 공부하게되면 이도저도 아닌 것 같이 보일까 걱정이긴하지만, 수료 후 취업 할 수 있는 기업수가 많아질 수 있어 좋겠다고 생각했고) 혹은 플러터 부트캠프가 있습니다. (기존 포트폴리오에 플러터 프로젝트가 하나 있어서 이와 연계해서 좀더 딥다이브하기 위해 플러터 부트캠프를 다니려고 했습니다

NextJS13 app라우터 컴포넌트 설계 질문드립니다.

안녕하세요. NextJS13을 사용하여 팀 프로젝트를 진행하고 있습니다. 프로젝트 내 게시판 페이지에서 페이지네이션을 개발하던 도중 궁금한 내용이 있어 질문드립니다. 현재 게시판 메인페이지에서 데이터를 가져와서 페이지네이션 컴포넌트로 프롭스로 전달하는 형태로 로직을 구현하였습니다. 과정에서 상태관리가 필요하여 훅을 사용하기위해 페이지 전체를 'use client' 키워드를 사용하여 클라이언트 컴포넌트로 변경하였는데 데이터 렌더링 부분은 서버에서 렌더링하려면 Container 컴포넌트를 별개로 생성하여 최상위 컴포넌트에서 데이터를 불러오고 프롭스로 전달하는 형태로 구현을 하면좋을지 솔루션을 듣고싶습니다. 기존에는 SEO등을 고려하여 사용자와 상호작용하는 부분(input, form 등등..)에 한해 클라이언트 컴포넌트로 구성하였는데 위와 같이 데이터를 불러오고 가공하는도중 리액트 훅이 필요할때 어떻게 설계하시는지 궁금합니다.