Component 분리 및 통합 시 어떤 방향을 선호하시나요?

우선 올려주신 방향들에 대해서 제 생각을 조금 나눠볼게요 🤗 • HOC / Wrapper Component 관심사를 분리하고, 공통 로직을 추출할 수 있어 좋은것 같아요. 단, HOC는 디버깅 난이도가 올라가고, 컴포지션이 깊어지는 문제를 가져올 수 있어서 고려하면서 꼭 필요한 부분에만 쓰는 게 좋은 것 같아요. • 2-3단계 정도의 props drilling 허용 지나치게 엄격한 추상화는 오히려 복잡도를 올릴 수 있어서요. FSD 관점에서 보자면, 레이어 사이에 위계가 명확한 범위 내에서는 props drilling을 허용해도 좋은것 같아요.(디버깅이 크게 어렵지 않아서요) • 코드 반복을 허용 중복을 피하려다 추상화가 복잡해지는 것보다는 명시적인 반복이 차라리 나은 경우도 꽤 있는 것 같아요. 특히 props 개수가 많아지는 상황에서는 DRY보다 clarity(명확성)가 더 중요할 수 있어서요. • context / provider 사용 저는 가능한 상태를 줄이자 특히 글로벌 상태는 더더욱 이라고 생각하긴 하는데요.. 왜냐면 depth를 줄이는 대신 coupling을 높이는 부작용? 도 있어서요. 그래도 이런 트레이드오프를 잘 고려하면서 쓴다면 괜찮을것 같기도 해요..! 컴포넌트를 통합하기 이전에, 아래 부분도 먼저 고민해보면 좋을것 같아요 • 단순히 UI 컴포넌트를 통합하기보다, props가 많은 이유가 로직이 퍼져 있기 때문이라면, 해당 부분을 hook 으로 분리하는게 유리할 수도 있어서요. 이를 통해 받는 props 수를 줄일 수도 있을 것 같아서요. • 위와 같은 맥락인데, 동일한 UI라도 비즈니스 로직을 다양한 방식으로 잘 분리하면 props 가 줄어들기도 하는것 같아요. hook 외에도, 전역 상태나 url, History 등을 활용해서요.(위 4번에서 얘기한 트레이드오프를 고려해야할 것 같아요..!)

적절한 추상화의 기준을 만드는 게 중요한 것 같아요. 컴포넌트가 여러번 반복되어서 통합 했을 때 props가 많아진다면, 이것은 완벽한 중복은 아닐 것 같고 비슷한 요구사항을 만족시키는 컴포넌트들을 통합하는 과정에 생긴 현상일 것 같은데요. 이 추상화의 단위가 적절할지 먼저 고민해볼 것 같네요! 기본적으로 props drilling 자체는 문제가 된다고 생각하지는 않아요. 이런 과정에서 복잡도가 높아지면 그게 문제라고 생각하구요. 이런 과정을 거친 이후에 추상화를 해야한다면 1, 2, 4 모두 필요에 따라 사용할 수 있다고 생각하고, 3도 좋은 방법이라고 생각해요. 코드 중복으로 먼저 작성한 이후에 추상화를 하는 것은, 추상화를 한 모듈을 쪼개는 것보다 더 쉽기는 하니까요!