중복 코드 허용하기 | Frontend Fundamentals

[giscus[bot]]

중복 코드 허용하기 | Frontend Fundamentals

변경하기 쉬운 프론트엔드 코드를 위한 지침서

https://frontend-fundamentals.com/code/examples/use-bottom-sheet.html

[kwaneung]

안녕하세요. 좋은 내용의 글 감사합니다.

공통화하는 기준에 대한 질문이 있습니다.

어느 정도로 중복되면 공통화를 하고, 공통화를 할 때 얼마나 넓은 범위를 공통화해야 하는지가 궁금합니다.

예를 들어 점검 바텀 시트를 닫을 때 화면을 같이 닫을지 여부 조건을 주는 쪽으로 훅을 만들어 공통화하는 방식도 있을 텐데, 공통화 한 부분에 어느 정도의 분기 범위를 포함해야 하는지가 궁금합니다.

[jungpaeng]

안녕하세요, 이 부분은 정답이 없는 문제인 것 같아서 사람마다 생각이 모두 다를 것 같습니다.

이 부분에 대해서 명확한 해답을 제시하기보다는 제가 읽었을 때 도움이 된 글들을 소개해보겠습니다.

• AHA(Avoid Hasty Abstractions) 프로그래밍
  • https://kentcdodds.com/blog/aha-programming (원문)
  • https://goongoguma.github.io/2021/05/02/AHA-Programming/ (번역)
• 잘가, 클린 코드
  • https://overreacted.io/ko/goodbye-clean-code/
• 성급한 추상화에 관하여 - AHA Programming (Kent C. Dodds)
  • https://365kim.tistory.com/77
• 중복은 잘못된 추상화보다 저렴합니다
  • https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction (원문)
  • https://hoilzz.github.io/etc/wrong-abstraction/ (번역)
• 단단한 컴포넌트 부수기
  • https://kwoncheol.me/posts/break-the-component
• 확장하기 쉬운 코드가 아닌 삭제하기 쉬운 코드를 작성하자
  • https://harfangk.github.io/2016/10/30/write-code-that-is-easy-to-delete-not-easy-to-extend-ko.html
• 쉬운 도구는 디버깅하기 쉬운 도구다.
  • https://gompro.postype.com/post/3787808
• OOP를 빨리 잊을 수록 여러분의 소프트웨어에 좋습니다.
  • https://rinae.dev/posts/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-kr/
    • 만약 읽는다면, 꼭 역주 글까지 읽어주세요.
• DRY, WET, OR AHA?
  • https://medium.com/nerd-for-tech/dry-wet-or-aha-7c2132aaf047
• '중복이 잘못된 추상화보다 더 저렴하다는 것'을 구매하지 않는 이유
  • https://www.codewithjason.com/duplication-cheaper-wrong-abstraction/
  • 위에서 중복이 잘못된 추상화보다 낫다고 주장하는 글을 계속 작성했지만, 당연히 무분별한 중복은 나쁩니다.

• 제가 컴포넌트를 작성할 때는 비슷한 UI를 기준으로 컴포넌트를 나누지 않는데요. 제가 컴포넌트를 작성할 때 고려하는 점을 잘 설명한 발표가 있어서 공유합니다.

• https://youtu.be/HYgKBvLr49c
• https://youtu.be/YP7d9ae_VzI (릴레이를 사용하지 않더라도 알아두면 분명 좋을거라고 생각합니다)

---

'단단한 컴포넌트 부수기'에 대해서 의견을 덧붙입니다:

위 글에서 말하는 말하는 'useCallback을 이용한 최적화'는 사실 필요없을 가능성이 크다고 생각합니다.

위와 같이 작성한 이유는 React의 VirtualDOM이 해결하는 문제를 잘못 이해하는 경우가 매우 많기 때문인데요.

위 본문의 작성자는 props로 함수를 넘겨서 리렌더링이 되는 것을 useCallback 함수를 이용해 막을 수 있다고 최적화 방법을 제안합니다. 그렇지만, VirtualDOM이 하는 역할을 하나로 정의하면 'DOM을 업데이트하는 것은 느리니, DOM 업데이트를 묶어서 한번에 처리하자'입니다.

이처럼 일괄적으로 업데이트하는 것을 수행하기 위해 상태 변경이 있을 때 React는 현재의 ReactElement와 렌더링해야 할 ReactElement를 비교합니다. 이를 통해 DOM 업데이트를 수행할 것인지 알 수 있으며, 업데이트를 수행해야 한다면 한번에 묶어서 DOM을 업데이트하고, 이를 "커밋"이라고 부릅니다.

render -> reconciliation -> commit
-> state change -> render -> ...

일반적으로 말하는 느린 부분은 리액트 렌더 부분이 아닌 실제 돔이 업데이트되는 "커밋" 단계이며, 모든 DOM 업데이트가 느리다고 할 수도 없습니다.

또한, reconciliation 단계를 통해 실제 돔을 업데이트할지 결정하고 있기에, render가 여러 번 호출된다고 DOM 업데이트가 필연적으로 발생한다고 할 수 없습니다. 흔히 말하는 불필요한 리렌더링은 DOM이 업데이트되지 않음에도 리액트의 렌더 함수가 호출되는 것을 이르는데, 일반적으로 이 렌더 단계는 매우 구형 모바일 기기의 브라우저에서도 빠르게 동작합니다.

그렇다면, 렌더 및 조정 단계가 그렇게 느리지 않다면 앱이 종종 멈추는 이유는 무엇일까요?
이는 렌더링 단계에서 코드를 실행시키는 과정 중 필연적으로 느리게 동작하게끔 하는 코드가 있을 수 있음을 의미하는데요. 이를 프로파일러를 통해 진단 후 해결하는 작업이 필요합니다. 이런 문제를 리렌더링 횟수를 감소시켜서 해결할 수도 있지만, 원인 자체를 해결한 것은 아니기 때문에 상황이 악화될 가능성이 큽니다.

위에서 작성한 리액트 렌더링 횟수에 집착할 이유가 전혀 없는 이유에 대해서 트위터의 사례가 간단히 영상으로 나와습니다.

https://twitter.com/asidorenko_/status/1596468945321865216?s=46&t=aLO5O-zBL9EKV7jifx-o5g

https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render 글에서 많은 부분을 인용해서 링크를 함께 남깁니다.

[airman5573]

댓글을 안달수가 없네요, 깔끔한 정리 감사합니다!