(공통): 아직 벡엔드 팀도 안나왔고, 주제도 정하지 못해서 ‘recoil을 써야할까?’ 고민중 입니다. 3주 정도 진행하는 프로젝트에서 recoil을 써서 상태관리를 할 일이 있을지? 도입한다면 어떤 식으로 공부하면서 도입하면 좋을지 궁금합니다.
- 승환님 - 적용경험 있음
- 지원님 - setup이후로 진행
→ 쓰는걸 추천한다. 왠만하면 recoil 사용하는 구조 된다. 쓰는 방식은 하면서 공부하기.
(재관): 폴더 구조를 살펴보면 Page와 Component가 구별되어 있는 모습을 자주 봅니다.
Page는 View를 담당 하는 것 같고 Component는 로직을 담당하는 것 같은데 어떤 기준으로 분리해야 할지 잘 모르겠습니다.
(e.g. Postlist에서 조건 따라 필터링이 필요하다면 필터링 로직은 Page에 포함되어도 괜찮을까? 아니면 필터링 된 결과물을 받아서 보여주는 역할만 해야 할까? )
→ 로직을 UI와 분리하기 → 함수로 분리할수있는 로직은 분리하고 테스트 할 수 있는 정도로
→ UI 통합 테스트
→ 로직은 유닛 테스트
→ pure component 만들때 로직을 완전히 없이
→ atomic component design pattern 참고하기
→ page → domain component → pure component
→ page renders domain component
→ domain components : 로직 처리
→ pure component : 재사용
(재관): Typescript에서 필요한 데이터를 Fetch 받아서 JSX에 사용할 때 ‘데이터가 undefined일 수 있다’는 에러를 해결하기 위해서 ‘data?.’를 많이 사용했습니다. 추후에는 JSX에 삼항연산자를 사용하여서 데이터가 있을 때만 JSX의 내용들이 표기되도록 하였습니다. 데이터의 타입을 확정 짓고 싶어서 사용한 방법이었는데 더 좋은 방법이 있을까요?
→ 데이터 fetch에서 데이터 없으면 catch(error) → possibly undefined가 없어진다
→ catch 못하는 상황에는 → react suspense 활용하기
→ data를 가져올 때, error를 처리하는 코드를 추가 혹은 앞단에서 한 예로 suspense layer를 두고 처리
// suspense layer 처리 async function fetchItem() {} const getItem: Item | undefined = await fetchItem({..}) // undefined : 에러 상황/로딩 상황 if(!getItem) throw new Errow(...); data.item.
(승환) : 일단 저희가 생각해둔 상태관리는 리액트 쿼리, 리코일입니다.
현재 상태관리를 api 관련된 부분은 리액트 쿼리,
클라이언트 상태관리는 리코일을 쓸려고 합니다.
거기다 next.js를 쓸려고하고
시간이 되면 테스트 코드도 짤려고하는데
기술을 너무 욕심내는건지 아니면 적당히 저희가 사용할 수 있는 기술을 골라야하는건지 멘토님 의견을 들어보고 싶습니다.
그리고 현업에서는 새로운 기술을 적용할때 어떠한 방식으로 적용을 하는지 의견을 들어보고 싶습니다.
→ 스펙은 딱이다
→ 개발 속도에 block 안할정도면 괜찮다
→ 테스트 코드 보단 완성하는거에 우선 → 백엔드와의 협업 경험
→ 테스트 코드는 환경 셋팅 정도?
→ 현업에서는 신기술 도입하는 담당자가 따로 있다 (Proof of Concept)
→ 진입 장벽을 나출수있는지? 도입 strategy? migration strategy
→ expected outcomes도 계산해서 pros > cons 하는지 고려
(미현) : 백엔드와 협업해서 프로젝트를 할 때, 보통 어떤 순서로 일정을 진행하면 좋을 지 궁금합니다.
이전에는 백엔드가 이미 구축이 되어 있어서, 프론트엔드 파트에서 기획하고, 바로 구현하는 순서로 진행되었는데, 최종프로젝트처럼 처음부터 협업해야 하는 경우에는 어떻게 진행하면 좋을 지 조언을 듣고 싶습니다
→ 기획서가 나온다 → 이거 기준으로 각자 파트 나누기 (여기선 db 관련 로직이 필요할거다, 등등)
→ 어떤 api가 필요하는지에 대해 기획서 보면서 스펙 정하기
→ response 구조는 찾아보기
→ api 문서받으면 테스트해보기
→ api가 늦게 나온다 → 모킹 데이터 활용하기
→ 어떤 구조로 만들겠다 정해지면 (ie. endpoints) 모킹 데이터 이용하기
→ 백엔드 쪽에서도 도입해보고싶은 기술들이 있을거다 → 그때 프론트 일정도 고려하면서 협의하기
→ UI작업하면서도 flow에 대한 부분을 조금이라도 같이 가져가자.
(지원) : 지난 프로젝트때 스타일 컴포넌트를 사용하면서 겹치는 부분도 많아 중복된 컴포넌트 (예. container)에 대한 코드가 많았습니다. 이런걸 고려해서 css-in-js 보다 그냥 클래스네임으로 css가 낳을지? css 모듈을 사용하는거는 어떤지? 실무에선 공통 스타일에 대해 어떻게 분리하고 관리하는지 궁금합니다.
→ 중복 컴포넌트 처리 ⇒ 팀원간의 커뮤니케이션을 통해서 해결할 수 있다.
- 사전에 차단하는 방법
- 사전에 계획 같은 것을 팀원들과 공유하자
- PR 단계에서도 리뷰를 줄 수 있다.
→ 각 컴포넌트마다 들어가는 중복 스타일 코드에 대한 해결 방법
- 상속받을 수 있다면 상속해서 사용하자 ex) extends
- className으로 묶을 수도 있다
- ex) sass의 mixin, tailwind
→ css-in-js가 왜 비추인가, tailwind를 추천하시는지
- css-in-js
- 런타임 때 스타일처리 과정이 존재할 수 있다.
- 빌드일 때, 트랜스파일링 과정이 존재할 수 있다.
- tailwind, css의 처리과정과 비교했을 때, css-in-js보다는 덜 비용이 소요된다.
- 반면, react에서 component단위로 스타일 처리하게 되면 css-in-js가 가독성이 좋을 수 있다. (비용 vs. 가독성)
- 지금 프로젝트 기준에서는 성능보다는 가독성, 팀원들이 무엇이 더 익숙한 가에 대해서 더 중요하게 생각하는 것도 good!
- tailwind로 중복 피하고, emotion으로 런타임 스타일링.
- linaria ?