테스트코드를 짜본적이 없어서, 여러 문서들을 보면서 테스트코드를 어떻게 설계하고 어떻게 도입해야할지 찾아보면서 든 생각이다.
테스트코드로 컴포넌트와 함수들을 테스트하기 위해선, 내부복잡성이 많이 떨어져야 테스트코드 작성이 쉽다는 것을 알았다. 여러 관심사가 하나의 함수 또는 컴포넌트에 모두 몰려 있다면 이것은 테스트가 불가능한 함수/컴포넌트인 것이다.
결국엔 자연적으로 적절한 추상화 단위로 쪼개줘야한다는 결론이 나오고, 이는 퓨어펑션, 퓨어 컴포넌트를 의미한다.
기능단위로 추상화할 것 인가? 맥락/플로우 단위로 추상화할 것인가? 비지니스 단위로 추상화할 것인가?
비지니스 단위가 가장 큰 덩어리이고, 그다음이 하나의 맥락 또는 플로우, 그다음이 기능단위 인 것 같다. 기능단위로 모두 분리하면 좋은 코드일까? 테스트하기는 쉽지만 너무 추상화 되어 있기 때문에, 리더빌리티를 해치고 중복된 코드를 양상하게 되어 데드코드 발생률이 높아진다.
그럼 어떻게해야 컴포넌트를 잘 설계할 수 있을까?
여러 문서들을 찾아보고, 어떻게 하면 좋을 지 생각해보는 시간을 가져야겠다.
최대한 많은 아티클을 찾아보고 나만의 기준과 방법을 만들어보자
https://blog-tech.tadatada.com/2022-08-08-redux-again
https://blog.jbee.io/react/Testing+0.+React+Testing+%EC%8B%9C%EB%A6%AC%EC%A6%88%EB%A5%BC+%EB%93%A4%EC%96%B4%EA%B0%80%EB%A9%B0
https://blog.jbee.io/react/Testing+3.+Store%EC%99%80+%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4+%EB%A1%9C%EC%A7%81+%ED%85%8C%EC%8A%A4%ED%8A%B8
https://blog.jbee.io/react/React+3.+React+Architecture
https://toss.im/slash-21/sessions/3-3
https://toss.im/slash-23/session-detail/A1-3
https://jbee.io/web/components-should-be-flexible/
https://fe-developers.kakaoent.com/2023/230330-frontend-solid/
https://fe-developers.kakaoent.com/2022/220731-composition-component/
https://ms3864.tistory.com/433
https://fe-developers.kakaoent.com/2022/221020-component-abstraction/
https://velog.io/@teo/gradation-thinking
https://velog.io/@eunbinn/react-docs-recommendations
아래는 선언적으로 컴포넌트 만드는 예제
https://velog.io/@hhhminme/ts-pattern%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-%EA%B0%95%EB%A0%A5%ED%95%9C-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EB%A7%8C%EB%93%A4%EA%B8%B0
https://github.com/toss/slash/blob/main/packages/react/react/src/components/SwitchCase/SwitchCase.tsx
리액트 공식문서
https://react.dev/learn/keeping-components-pure
https://react.dev/learn/you-might-not-need-an-effect
