본문 바로가기
프론트엔드

프론트엔드 설계 고민 -4-

by ISA(류) 2022. 5. 21.

UI적인 측면은 컴포넌트와 아토믹 패턴을 통해서 feature를 구성한다. 데이터 처리 관련은 스토어, 커스텀훅(컨테이너)으로 처리한다.(model, viewmodel) 그렇다면 공통 feature는 어떻게 처리할까? 그러니까 위젯처럼 동일한 UI로 데이터 패칭이 필요해서 그 컴포넌트 내부에서 데이터를 패칭하고 그 구성을 여러 도메인에서 가져다 쓰는 경우가 존재 하는 경우 말이다.

 

개인적으로는 이럴 경우 해당 로직이 아예 동일하다 할지라도 도메인 영역이 다르기 때문에 공통되는 feature를 공유하기 보다는 같이 쓰는게 맞다고 본다. 도메인 별로 컨셉이 달라질 수 있는데 그럴 경우 영향을 받는게 바람직 하지 않다고 생각 되기 때문이고, 만약에라도 도메인에 상관 없이 동일한 인터페이스와 데이터를 제공해야 할 경우 프로젝트에서 분리된 위젯이나, 플러그인 등으로 만들어서 사용하는게 맞다고 본다.(오픈 API처럼) 또 웹앱과 실시간 데이터 교환이 필요할 경우 이것은 feature와 다르게 데이터를 props 방식으로 주입하는게 더 적절하다고 생각한다.

 

그게 UI와 데이터를 분리하는 추상화 레이어를 유지하기도 좋고 말이다.  또 feature가 다른 도메인의 feature를 참조하는 것 자체가 직관적이지 않다.  같은 추상화 단계에서 서로 다른 도메인의 feature를 참고할 경우 굳이 feature를 도메인별로 쪼갠 이유가 없다. 책임이 미세하게 달라진다. 세부 구성이야 어차피 공통 된 부분은 죄다 하위 레이어에서 추상화 될테니 공통된 부분이 거의 존재하지 않기도하고 말이다.

 

즉, 그런 경우는 거의 없겠지만 도메인별 동일하게 사용 되는 feature라 할지라도 서로 다른 도메인의 feature를 참조하는 방식으로 공유하지 않는다는 것이다. 그럴 경우 해당 feature를 따로 위젯(또는 shared) 등으로 분리해서 관리하는게 더 적절한 관리 방법이다.

 

feature를 여러 방식(다국어등)으로 제공하는 경우 클래스 101 기준으로는 shell이라는 명명으로 추상화 레이어를 추가해서 제공하는데 이부분은 글로벌 관련해서 작업을 해본적이 없기에 더 좋은 방법은 딱히 떠오르지 않는다. 다만 로컬 사이트의 경우 feature의 상위 레이어가 당장은 필요없을 것이라 보인다. 같은 라우팅에서 적응형으로 제공한다거나 하는 경우가 아닌 경우 말이다. 그리고 다국어 사이트 역시 라우팅을 따로 제공한다고 하면 굳이 추상화 레이어를 추가해서 같은 웹앱에서 관리할 필요가 있을지는 의문이다. 이 부분은 실제 경험이 없으므로 추측할뿐이다.

 

대략적인 feature에 대한 방향성이 정해졌다. 그렇다면 위젯도 아니고 feature도 아닌 일종의 공통 컴포넌트이자 순수한 UI라고 볼 수 도 없는 컴포넌트의 경우 어떻게 해야할까? 예를 들어서 회원 인증 정보에 따라서 권한 처리를 하는 그런 컴포넌트의 경우 순수하게 UI라고 볼 수 도 없고 feature라기엔 여러 곳에서 중복으로 사용되면서도 그것을 수정 할 책임이 도메인 별로 다양하지 않다. 이 경우 그를 provider나 vender등으로 명명해서 따로 관리하는게 적절하다.

 

결국 프론트 설계의 방향성 역시 OOP의 SOLID에서 크게 벗어나지 않는데 현재 모던 개발의 메인 스트림상 OOP를 완전히 대체할 패러다임 시프트가 일어나지 않았기에 그런 것으로 보인다. FP 패러다임 역시 기존 OOP와 상호 보완적인 관계를 가지는 방식으로 사용 되고 있으니 한동안은 해당 흐름이 지속될 것이다. 어쩌면 쭈욱.

 

정리하자면 feature는 각 도메인에 맞게 공통 UI는 최대한 빼내고, 각 도메인에 맞게 feature의 책임으로 구분하고

책임상 필요할 경우 feature 상위 레이어로 보통 shell.

그리고 여러 도메인에서 쓰이면서 feature가 완벽히 독립적이면 따로 빼내서 보통 위젯으로

독립적이지 못하지만 책임이 동일할 경우 provider.

기본적으로 단일책임원칙을 지켜서 설계한다.

 

* 해당 부분들은 클래스 101 엔터프라이즈 설계를 많이 참고했다.

https://medium.com/class101/%EC%97%94%ED%84%B0%ED%94%84%EB%9D%BC%EC%9D%B4%EC%A6%88-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-79eef2e30c77

 

엔터프라이즈 프론트엔드 애플리케이션 아키텍쳐

소프트웨어의 수명과 복잡도는 대개 비례 관계입니다. 아무리 정교하고 아름답게 코드를 작성해도, 시간이 지날수록 코드베이스는 복잡해지기 마련입니다. 그래서 우리는 이런 문제들을 마법

medium.com

 

반응형

'프론트엔드' 카테고리의 다른 글

[JS]스와이프 기능을 만들어보며.  (0) 2022.07.02
[React] React-dom에서의 innerHTML  (0) 2022.05.31
프론트엔드 설계 고민 -3-  (0) 2022.04.26
[React]React와 JSX.  (0) 2022.04.14
리액트 포탈과 렌더링 고민  (0) 2022.04.09