디자인패턴7 프론트엔드 설계 고민 -6- 요즘 운동에 빠져서 개발을 소홀히하고 있다. 그래서 글쓰는 것도 프로젝트 진행도 느긋하게 지연 되는데.. 원래 쓰려던 내용은 UI 컴포넌트를 구성하는 법에 대한 디테일이였지만 최근에 상태관리에 대해서 어려워 하는 사람들이 많은걸 봐서 인지 상태관리에 대해서 조금 정리하는게 좋을거 같다는 생각이 들었다. 웹 프론트엔드에서의 상태관리 도구의 경우 여러가지가 있지만 큰 맥락은 변하지 않으므로 익숙한 react와 recoil 기준으로 생각을 간단하게 정리해보겠다. 웹프론트 개발자는 웹 어플리케이션을 만든다. 그런데 왜 굳이 웹 사이트를 웹앱이라고 하는 것일까? 오늘날에 와서는 엄밀한 구분이 불가능한 편이지만 기존의 웹 사이트의 경우 정적인 웹에 가까웠다. 단순히 마크업 된 페이지를 제공해주고 사용자 액션에 따라.. 2022. 10. 3. 프론트엔드 설계 고민 -5- 큰틀은 대략적으로 잡았으니 조금 더 작은 부분들을 고민해보자. SPA 개발 즉, 모던 웹개발로 들어오면서부터 웹프론트의 UI의 경우 기본적으로 기존의 페이지 단위나 템플릿 단위의 개발에서 컴포넌트 단위의 개발로 개념이 조금 변경 되었다. 기존에는 마크업이나 스타일링을 HTML과 CSS로 그리고 JS로 필요한 동적인 조작을 하는 정도 였다면 모던 웹개발에서는 JS를 기반으로 HTML(마크업)과 CSS(스타일링)등을 모두 관리한다. (예: JSX) 그러다보니 기존 HTML, CSS와 많은 부분 같으면서도 다른 특징을 가지는데 HTML,CSS와 JS로 된 DOM, CSSOM의 차이점에서 오는 부분이라고 볼 수 있다. HTML과 CSS, JS로 개발을 진행할때는 각 영역이 독립적이고 서로 침범하지 않는게 미덕이.. 2022. 7. 10. 프론트엔드 설계 고민 -4- UI적인 측면은 컴포넌트와 아토믹 패턴을 통해서 feature를 구성한다. 데이터 처리 관련은 스토어, 커스텀훅(컨테이너)으로 처리한다.(model, viewmodel) 그렇다면 공통 feature는 어떻게 처리할까? 그러니까 위젯처럼 동일한 UI로 데이터 패칭이 필요해서 그 컴포넌트 내부에서 데이터를 패칭하고 그 구성을 여러 도메인에서 가져다 쓰는 경우가 존재 하는 경우 말이다. 개인적으로는 이럴 경우 해당 로직이 아예 동일하다 할지라도 도메인 영역이 다르기 때문에 공통되는 feature를 공유하기 보다는 같이 쓰는게 맞다고 본다. 도메인 별로 컨셉이 달라질 수 있는데 그럴 경우 영향을 받는게 바람직 하지 않다고 생각 되기 때문이고, 만약에라도 도메인에 상관 없이 동일한 인터페이스와 데이터를 제공해야 .. 2022. 5. 21. 프론트엔드 설계 고민 -3- 설계의 기본적인 규칙은 벡엔드나 프론트엔드나 대동소이하다.(사실 프로그래밍 외적인 분야로 봐도 비슷한 거 같다) 하나의 컨셉(관심사)에 집중한다. 하나의 행동(목적)을 여러 단계로 추상화하고 그 단계에 적합한 관심사에 맞는 부분에 집중해서 처리한다. 그런 작은 단위의 작업을 목적을 완성할 때까지 반복한다. 그리고 해당 목적의 디테일이 달라졌을때 또는 그런 추상화한 구조를 다른 목적을 수행하는데 재사용 가능하게 한다. 내가 철학적인 성향이 강해서 그런지 개인적인 생각을 말하자면 프로그래밍 자체가 철학과 유사하다는 생각이 많이 든다. 어떤 관심(목적)을 위해서 지속적으로 추상화된 보편율(코드)를 구하고 그를 검증하고 다듬는다. 물론 그렇게 개발을 하지 않는 사람도 많겠지만... 적어도 나는 그렇게 생각하고 .. 2022. 4. 26. 이전 1 2 다음