[FE] 리액트 패턴

[imgoing222]

프로젝트 패턴 적용에 대해서 의논하고 싶습니다.

이 부분에 대해서 논의한 적이 없어서 아마 현재 뷰와 비즈니스 로직이 거의 분리가 되어있지 않을텐데 컴포넌트 내부에 무언가 추가되는 로직이 생기면 너무 복잡하다는 느낌이 듭니다... 😥

custom hook을 사용해서 분리하는 패턴을 간단하게 사용해본적이 있는데 파일 수가 많아진다는 명확한 단점이 있긴 했지만 아예 분리하지 않는 것보다 더 선언적으로 코드를 작성하게 되고 가독성이 좋아진다고 느꼈습니다.

아래 링크들이 현재 제가 읽고 있는 글들인데 한 번 읽어보시고 의견을 주시면 감사하겠습니다 😀

https://youngmin.hashnode.dev/react https://velog.io/@teo/MVI-Architecture https://kjhg478.tistory.com/41 https://velog.io/@dnr6054/%EC%9C%A0%EC%9A%A9%ED%95%9C-%EB%A6%AC%EC%95%A1%ED%8A%B8-%ED%8C%A8%ED%84%B4-5%EA%B0%80%EC%A7%80

[jin0106]

올려주신 링크들 잘 봤습니다! 덕분에 몰랐던 패턴들에 대해서 알게됐어요 음.. 저도 생각을 해봤는데, 현재 로직들이 다른곳에서 사용되는 로직들이 아니고 해당 컴포넌트 혹은 페이지에서만 사용이 되는 로직들인데 응집성을 고려해보았을때 굳이 나눌 필요가 있을까라는 생각이 드는데, 혹시 이 부분에 대해서는 어떻게 생각하시는지 궁금합니다.

[jin0106]

또한 Button, Label, Input과 같은 여러곳에서 재사용이 가능한 컴포넌트들이 지금 여러개 존재하는데, 추후에 하나만 남겨서 관리하는걸로 리팩토링 해보는건 어떨까요?

[imgoing222]

확실히 단점도 존재해요. 저희 프로젝트를 봤을 때도 굳이...? 라고 생각되는 부분도 더러 존재하구요.

그래도 지금 pages/createSale.tsx 와 같이 로직이 아주 긴 컴포넌트도 있고, 뷰와 비즈니스 로직을 분리해놓고 봤을 때 컴포넌트나 custom hook 재사용성에 대해서 고민할 때 더 편리하다고 느꼈어요.

그리고 뷰와 비즈니스가 분리되다보니 뷰만 봤을 때도 어떻게 작동하는지 대략적으로 파악할 수 있게 작성해야하니까 더 정확한 함수명과 변수명을 쓰려고 노력한다는 장점도 있었구요! 전체적으로 가독성을 높여준다는 느낌이 강했습니다 😀

https://github.com/woowacourse-teams/2022-gong-check/tree/dev/frontend 위 링크의 프로젝트가 Custom Hook Pattern으로 구성되어 있는데 한번 보시고 다시 의견 나눠봐요!

[imgoing222]

또한 Button, Label, Input과 같은 여러곳에서 재사용이 가능한 컴포넌트들이 지금 여러개 존재하는데, 추후에 하나만 남겨서 관리하는걸로 리팩토링 해보는건 어떨까요?

안그래도 버튼을 만들때마다 버튼을 계속 만들어야할까... 하는 고민을 했었는데 좋을 것 같습니다! 그러면 버튼 속성같은거는 props로 전달해서 용도에 따라 변경할 수 있는 컴포넌트로 만드는 건가요?

[jin0106]

해당링크 레포의 코드들을 보고 createSale꺼를 다시 보니 역체감이 심하네요😅 확실히 컴포넌트에서는 뷰만, 커스텀 훅에서는 로직만 구분이 될수있어 가독성이 훨씬 좋네요. 유지보수에도 더 좋을거같아요. 한번 바꿔보는것도 좋을거같습니다! 대신 커스텀 훅과 컴포넌트 파일을 어떻게 같이 관리할지도 다시 한번 생각해보는것도 좋을거같습니다

[jin0106]

또한 Button, Label, Input과 같은 여러곳에서 재사용이 가능한 컴포넌트들이 지금 여러개 존재하는데, 추후에 하나만 남겨서 관리하는걸로 리팩토링 해보는건 어떨까요?

안그래도 버튼을 만들때마다 버튼을 계속 만들어야할까... 하는 고민을 했었는데 좋을 것 같습니다!

그러면 버튼 속성같은거는 props로 전달해서 용도에 따라 변경할 수 있는 컴포넌트로 만드는 건가요?

네 일단 제 생각은 그렀습니다! 색깔을 props로 주면 될거같은데, 제가 고민인건 width랑 height을 props로 주고 반응형을 어떻게 구현해야하나 고민이네요. 좋은 의견있으면 남겨주시면 감사하겠습니다

[jin0106]

유지보수 측면에서 비즈니스 로직을 담당하는 커스텀훅과 뷰를 담당하는 파일을 같은곳에 두고 관리하는게 편하다고 생각을 해서, pages의 각 폴더안에 추가 폴더를 만들어서 관리를 할까 햇는데 next.js 라우팅 특성 때문에 안되겠더라구요. components 폴더는 전역에서 재사용 가능한 컴포넌트들만 놔두고 Container라는 폴더를 만들어서 그 안에 각 페이지에 해당하는 폴더들을 만들고 이안에서 다시 해당 페이지에서만 사용하는 것들을 관리하면 어떨까요?? 지역성의 원칙을 고려한 구조인데 아래 링크 읽어보시면 좋을거같습니다.

https://ahnheejong.name/articles/package-structure-with-the-principal-of-locality-in-mind/

[jin0106]

그리고 이건 컴포넌트에 관련된 링크인데, 데이터 중심으로만 컴포넌트를 분리했던 저희의 문제점과 어느정도의 해결방법이 잘 나타와있는거 같아요 https://jbee.io/web/components-should-be-flexible/

[imgoing222]

그리고 이건 컴포넌트에 관련된 링크인데, 데이터 중심으로만 컴포넌트를 분리했던 저희의 문제점과 어느정도의 해결방법이 잘 나타와있는거 같아요 https://jbee.io/web/components-should-be-flexible/

네 저도 뚜렷한 기준 없이 컴포넌트를 분리했던 거 같아서 여러가지 글을 읽어봤는데 해당 링크도 감사하게 잘 읽어볼게요! 😀 https://velog.io/@rat8397/%EA%BC%AD%EA%BC%AD-%EC%9A%B0%EB%A6%AC%EB%93%A4%EC%9D%98-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8 위 링크는 컴포넌트 재사용에 대해서 많이 고민한 분들이 작성한 글이라 혹시 공통으로 재사용하는 컴포넌트가 생긴다면 그 기준에 대해서 의논할 때 참고해봐도 좋을 거 같아요!

[imgoing222]

유지보수 측면에서 비즈니스 로직을 담당하는 커스텀훅과 뷰를 담당하는 파일을 같은곳에 두고 관리하는게 편하다고 생각을 해서, pages의 각 폴더안에 추가 폴더를 만들어서 관리를 할까 햇는데 next.js 라우팅 특성 때문에 안되겠더라구요. components 폴더는 전역에서 재사용 가능한 컴포넌트들만 놔두고 Container라는 폴더를 만들어서 그 안에 각 페이지에 해당하는 폴더들을 만들고 이안에서 다시 해당 페이지에서만 사용하는 것들을 관리하면 어떨까요?? 지역성의 원칙을 고려한 구조인데 아래 링크 읽어보시면 좋을거같습니다.

https://ahnheejong.name/articles/package-structure-with-the-principal-of-locality-in-mind/

오...! 안그래도 component가 너무 중구난방이라고 생각했는데 좋은 방법 같아요! 당장 적용해볼 수 있을 거 같네요~!!!

[imgoing222]

해당링크 레포의 코드들을 보고 createSale꺼를 다시 보니 역체감이 심하네요😅 확실히 컴포넌트에서는 뷰만, 커스텀 훅에서는 로직만 구분이 될수있어 가독성이 훨씬 좋네요. 유지보수에도 더 좋을거같아요. 한번 바꿔보는것도 좋을거같습니다! 대신 커스텀 훅과 컴포넌트 파일을 어떻게 같이 관리할지도 다시 한번 생각해보는것도 좋을거같습니다

네 일단 제 생각은 그렀습니다! 색깔을 props로 주면 될거같은데, 제가 고민인건 width랑 height을 props로 주고 반응형을 어떻게 구현해야하나 고민이네요. 좋은 의견있으면 남겨주시면 감사하겠습니다

넵! 그럼 custom hook 디자인 패턴으로 한번 리팩토링 해봐요~! custom hook 파일도 위에서 의견 주신 Container 폴더에 포함시키는 방향은 어떨까요? Next.js 가 별도의 설치할 router없이 라우팅 시켜준다는 장점이 있긴한데 또 이런 단점이 생기기도 하네요 ㅎㅎ...

공통 컴포넌트 반응형 디자인에 대해서는 저도 좀 더 생각해보겠습니다!