해결된 질문
작성
·
436
답변 1
0
안녕하세요! Chansoo님!
컴포넌트 구조를 설계하시는데에 도움을 드리자면, 우선 너무 깊은 depth는 자제해 주시는게 좋을 것 같아요!
물론 예외는 있겠지만, 최대 4단계정도로만 내려가겠다! 정도를 기준으로 잡아주시면 좋을 것 같아요!
이러한 상황아래, 마지막 depth에 존재하는 단위 컴포넌트(또는 아톰 및 몰러큘정도)는 일반적으로, 유저서비스, 관리자서비스, 사장님서비스 등 여러 프론트엔드에서 재사용해야하므로 일반적으로 사내 private npm에 라이브러리로 올려놓고 다운로드 받아서 사용하게 됩니다.
따라서, 이 최종depth로의 props 이동은 반드시 필요하며, 이를 제외하면 나머지 최대 2~3단계 정도의 drilling이 일어날 수 있겠어요!
여기서 나머지 2단계정도는 props.children을 활용한 컴포넌트 합성 방식으로 문제를 해결하실 수 있습니다.(수업에서 리팩토링 git에 포함되어 있으니 참고해 보세요!^^)
이렇게 되면, 정말 어쩔 수 없는 drilling을 제외하고는 hooks, 로컬데이터캐시(recoil), 서버데이터캐시(react-query 또는 apollo-client) 정도로만 깔끔하게 해결 가능합니다!^^
추가로, context-api는 불필요한 리렌더링(부모컨텍스트의 자식 A, B중 A가 바뀌면 B도 리렌더링 되는 문제) 문제가 있으므로 추천드리지는 않으며, 그럼에도 불구하고 위 3개 이외에 저장소가 필요하시다면, recoil을 나눠보실 것을 추천드려봅니다!^^
네! Chansoo님!
설계에 따라 많이 달라질 것 같아요!
따라서, drilling이 많이 일어나는 상황이라면 가급적 구조 재설계로 문제를 해결하시는게 더 효율적일 것 같아요!
만약, Searchbar와 list를 묶을 수 있다면 이를 묶어서 한번의 props 끌어올리기로 처리하시면 좋을 것 같아요!(물론 Searchbar 내부에서 drilling이 일어날 수 있으나 이는 Searchbar를 npm에 업로드하였다는 가정으로 배제하도록 할게요)
다음으로, Searchbar와 list를 묶을 수 없는(두 컴포넌트가 멀리 떨어진) 상황이라면 recoil 등의 전역상태를 사용하는 방법이 대안이 될 것 같아요!
가급적 설계를 검토하시어 심플하게 문제를 풀어내는게 장기적으로도 복잡도를 줄이며 유지보수성을 높일 수 있을 것 같아요!
답변감사합니다, context-api사용은 피해야겠네요,
추가로 하나만 더 질문드릴게요,
예를들어 아토믹패턴에서 searchBar컴포넌트가 몰러큘에 포함되고 searchPage에 비즈니스로직을쓰면 상태올리기를 3단가량 해야하는데 차라리 searchTerm상태는 recoil로 처리하는게 나을까요?