Yenowme commented 2 years ago

아토믹 디자인 패턴 수정

이슈에 대한 설명

단점

아토믹 디자인 패턴의 유지보수 어려움
분류에 맞춰 작업을 진행하다 보니 배보다 배꼽이 더 큰 경우

결론

컴포넌트 자체는 재활용 하되, 트리구조 변경

checkList

주의사항

nyeoni commented 2 years ago

TakeNote https://github.com/taniarascia/takenote/blob/master/src/client/containers/TakeNoteApp.tsx

Presentation & Container 구조

로직을 수행하는 컴포넌트와, markup을 통해 ui를 보여주는 컴포넌트가 분리된 패턴입니다. 그에 따라 앱의 기능과 ui에 대한 구분이 쉬워집니다. 같은 state를 다른 container에게 props 내림으로 상태를 공유 할 수 있습니다. 로직수행, markUp이 다른 컴포넌트에서 하기 때문에 유지보수가 쉽고, 재사용성이 뛰어납니다. 특히, markup 변경에 매우 유연합니다. 동일한 마크업, 컨테이너 레이아웃 (header, footer)는 반복해서 작성하지 않도 this.props.children 구현 할 수 있습니다.

presentational component

사용자가 직접 보고, 조작하는 컴포넌트 (ui와 관련 있습니다) state를 직접 조작하지 않으며, container component가 내려준 prop의 함수에 의해 state를 변경합니다. 그에 따라 useState, useCallback, dispatch등 state관련된 훅이 하나도 없습니다. 상태를 거의 가지지 않으며, 상태를 가진다면 데이터에 관한것이 아닌 ui 상태에 관한 것입니다. 종종, this.props.children을 통해 컴포넌트가 렌더됩니다.

container component

어떻게 동작하는지, 어떤 로직을 수행하는지에 관련있습니다. markup을 사용하지 않습니다. 스타일을 사용하지 않습니다. 데이터와 데이터 조작에 관한 함수를 만들고 present component에 제공합니다.

결론

위의 레포랑 같이 presentation & container 디자인 패턴을 사용하여 presentation 은 상태 관리가 없는 UI 컴포넌트들 그리고 container 는 상태관리가 필요한 컴포넌트로 분류해본다. 이러한 분류로 페이지의 유지보수성을 높히고 앞으로 오픈소스 관리할때도 편할 것이라고 판단된다.

사용했던 Atomic Deisgn Pattern 에 관한 고찰

리액트가 거의 처음이어서 각 컴포넌트들의 역할을 디자인패턴에 맞게 분류하는게 모호하고 어려웠다. 모든 컴포넌트를 분류할 때 클라이언트 단의 회의를 통해 이루어졌던 것 같아서 오픈소스로 사용할때 유지보수가 어려울 수 있다고 판단하였다.
각 분류를 하기 위해서 컴포넌트의 수와 코드가 더 많아졌던 것 같고 시간도 많이 써야 하는 디자인 패턴이라고 느꼈다.
우리가 하는 프로젝트에 비해 컴포넌트 분류가 많아져서 오히려 유지보수가 힘들 것 같았고, 현재 하고 있는 프로젝트는 많은 컴포넌트들을 사용할 일이 없어서 좀 더 직관적이고 간단한 Presentation Container 구조가 더 적합하다고 판단하였다. 그러나 기업 같은 큰 프로젝트의 경우 컴포넌트의 재사용성이 훨씬 커지기 때문에 그 부분에서는 좋은 디자인 패턴이 될 수 있다고 생각하였다.