❓ 과제는 어땠나요? - 상태관리
모든 부분들에 있어서 걸렸던 것은 선언을 App 에서 만들고 처리했던 것이 신경쓰였다.
- 전역으로 관리하는 체계를 만들지 않으면 어쩔 수 없긴 했다. 이번에 사용한다고 하면 Path 만을 관리하게 되므로 Context API 가 가장 적합했을 것.
❓다른 상태 관리를 사용하면서 Context 를 같이 사용하나요?
- 조타이 같은 것을 쓸 때 웬만하면 Context 를 같이 쓰는 방식으로 구현할 수 밖에 없다
❓과제는 어땠나요? - CSS 트랜지션
현업에서도 실제로 구현하는 경우는 많지 않다. 시간을 단축하기 위해서 라이브러리를 많이 사용한다.
❓팀 프로젝트 PR 리뷰를 어떻게 진행해야 할까요?
팀 규칙을 정해놓는데, 보통 리뷰어는 1~2명 정도가 하는 게 적당하다. (일종의 승인절차) 통과가 되었다면 해당 코드를 모두 다 이해했다는 의미이다.
✅ 멘토님네 회사에서 쓰는 P5 예시
P1: 꼭 반영해주세요!
P2: 적극적으로 고려해주세요!
…
P5: 그냥 의견입니다!
✅ feature 정해두기!
분업을 적절히 해서 A 라는 기능을 만든다고 하면 해당 기능 외의 것들을 구현하거나 리뷰하지 않도록 조심하자!
❓CSS 관리를 어떻게 해야할까요?
✅ CSS in JS vs SCSS
뭐가 더 좋냐고 대답할 순 없지만 멘토님의 회사에선 CSS In JS 를 주로 쓴다. 아니면 Tailwind 를 쓰는 회사가 많다. SCSS 만 따로 쓰는 경우는 거의 없다.
✅ CSS in JS
유지보수가 쉽다. 하지만 파일 크기가 커진다. 그래서 빌드 시간이 늘어나는 단점이 있다.
✅ Taiilwind
익숙해지면 클래스 이름을 통해 사용하기 편하지만, 제 3자가 봤을 때
뭔..뭔 소리여 싶은 경우가 있다.❓스타일 컴포넌트를 따로 만들어서 import 하면 어떻게 관리하나요?
회사에선 레이아웃 구조가 정해져있고, 반복적인 컴포넌트를 인지하고 있게 된다.
공통 컴포넌트가 아닌 경우는 각 페이지 별로 만들어서
import 하게 된다.❓types 파일들을 따로 관리하고 싶은데 어떻게 관리해야할까요?
types 폴더가 크게 두가지 종류가 있다.- 공통 영역 (📁 src 영역 바로 밑에 존재)
API, 로그인, 사용자 등 전반적으로 어디서나 사용하는 타입들은 공통 영역에서 폴더화를 시켜서 사용한다.
멘토님께선 타입에 대한 네이밍도 하는 편이다.
declare 사용!// 기존 방법 interface {IUser} from 'src/@types/api/login'; // declare 를 써서 경로 변경에 의한 에러 방지 imterface {IUser} from '@api/user';
- 페이지 단위의 types
❓리액트에서 커스텀 훅을 사용하는 방식을 잘 모르겠습니다. 공통 함수의 경우 그냥 파일로 분류해야할까요 커스텀 훅으로 만들어야 할까요?
function 🆚 custom hook
🐝 custom hook 으로 만들때의 장점이 뭔지 이해가 안됩니다.
👓 useInput 을 예시로 들어봅시다! input 이 아래와 같이 여러개 있을 때
<input name='id' onChange={(e) => onChange(// ... )} /> <input name='password' onChange={(e) => onChange(// ... )} />
onChange 에 대한 함수와 name 이 반복되는데, 일반 함수의 경우는 분리해도 반복적으로 호출하게 됩니다!<input name='id' onChange={handler} /> <input name='password' onChange={handler} />
🐝 함수랑 하는 일은 비슷한데 의미적인 걸 위해 사용하는 건가요?
👓 그렇다고 보시면 됩니다! 더 게으르게(편리하게) 사용할 수 있도록 만들면 좋습니다. 어디서 커스텀 훅을 만들어야 하는지 잘 모르니까 이렇게 고민하는 이유를 알 것 같습니다.
🐈⬛ 한번만 사용하는 경우는 훅으로 만들면 비효율적인가요?
👓 회사에선 굳이 안 할 테지만, 포트폴리오 용이나 클린 코드 용으론 괜찮습니다. 시간이 된다면 작업을 해도 좋을 것 같습니다!
❓컴포넌트 별 이벤트 핸들러도 별도 파일로 만들려고 하는데 멘토님의 의견은 어떠신가요?
이벤트 핸들러의 경우 특정 컴포넌트에서 수행이 되는 거니까, 이벤트 핸들러가 많다고 따로 만들어 관리하는 것은 불필요하다고 생각한다.
분리를 하는 습관을 가지는 것은 좋으나 너무 많은 분리는 오히려 역효과가 난다.
❓전역으로 관리하는 데이터는 계속해서 메모리를 먹나요? 필요한 데이터만 저장해두는 게 좋을까요?
모든 데이터를 저장하면 퍼포먼스 적으로 좋지 않다. 꼭 필요한 경우만 쓰려고 했으면 합니다. 메모리의 효율성 문제도 있겠지만 다른 문제들도 많다.
Context API 의 경우 데이터 하나가 바뀔 때마다 무조건 리렌더링이 일어나므로 렌더링 이슈를 조심하자.
❓styled component CSS 를 props 으로 관리해도 괜찮을까요?
style = { css`display:flex; border:none; border-radius: 5px; &:hover { cursor: pointer; background-color: #aefae3; } }
쓸 수는 있으나 쓰지 말라고 권장을 드린다! (렌더링 이슈 있음)
굳이 쓴다면
className 을 쓰거나, styled Component 의 props 에 따라 CSS 를 바꿔서 쓰는 것을 추천한다.