15. UI 빌더를 지탱하는 레고 블록 같은 아키텍처 만들기

코어 로직을 만들고 이를 가져다 쓰는 ui 빌더를 만듦
코어 로직 구현 시에는 리덕스를 가져다 씀 (undo, redo 와 같은 기능을 리덕스의 타임트레블링으로 처리할 수 있을거라 기대함.)

문제1. 너무 깐깐한 코어 로직

프로덕트 스펙을 구현하는데 자꾸 코어를 수정한다
컴포넌트 삽입 ux 를 팝업으로 결정해버리는 코어 훅들..
- ux 를 코어로직에서 결정해버림
왜 문제일까?
- 코어는 계층의 foundation인데, Foundation이 프로덕트의 스펙을 결정해버리는 셈이되는 것임
그럼 이 책임을 프로덕트로 다 넘겨면 되나?
- 2-계층 아키텍쳐는 책임을 두 곳에 분산하겠다라는 의지.

진단 1. 부족한 계층과 불명확한 책임

계층을 나누고 책임을 재설계 하다.
재료는 어떤 과정을 거쳐서 서비스 어플리케이션이 되기를 원하는가?
재료 (SDK) -> 에디터/뷰어 (UI 빌더) -> 서비스 애플리케이션
도메인은 UI 빌더의 편집 전략을 결정하는 핵심
- SDK 안에 있음.
- SDK 안에 있는 도메인이라고 부를만한 유틸 라이브러리들을 추출하여 계층을 하나 더 만듦
기초 라이브러리 및 유틸리티 -> 모델 및 상태 관리 reducers, entities, models -> UI빌더 -> 서비스 어플리케이션
프로덕트 스펙과 편집 전략을 책임을 분리하고, 계층을 나눌 수 있음
최종적으로 UI 빌더에서는 제품 스펙을 구현하는 것
따라서 제품 스펙은 UI 빌더에 존재

문제2. 너무 무거운 프로덕트 뷰

프로덕트 계층에서 만들어야 하는 UI 컴포넌트가 너무 많다.
- 코어가 부품을 주지 않아서

진단2. UI 파운데이션의 부재

자체 프로젝트를 만들 때는 공통 UI 체계를 갖추자
디자이너가 없어서, 기성품에서 시작하기로 함 (추후에는 랩핑하자)
디자인 시스템과 애플리케이션 계층 분리
추후에 다른 디자인시스템으로 교체되더라도, 쉽게 교체할 수 있도록 디자인시스템이 코어 라이브러리를 의존하지 않도록 설계함

문제3. 너무 긴 커스텀 동선

커스텀 컴포넌트 추가 할 때, 8군데를 고쳐야함

진단 3. 사용자 관점의 부재

설계 할 때, SDK 를 가져다 쓰는 사용자(개발자)의 관점이 부재했음
변경을 모듈화 하여 동선을 최소화 하자
블록의 자격 4가지
- 모델 (Model)
- 뷰 (View)
- 로직 (Logic)
- 프로퍼티 (Property)
관심사를 해체하고 적절한 위치에 배치한다. (사정을 가장 잘 아는 자에게 책임을 부여한다.)
프로퍼티는 UI빌더 계층에 넣어둠. 모든 블록마다 프로퍼티를 가지고, 그 프로퍼티에 따라서 인스펙터영역이 결정되는데 이걸 결정하는건 UI 빌더의 역할이라고 봄
- 다만, 블록의 역할은 '난 어떤 프로퍼티를 쓰고싶어'까지 인 것임
블록은 UI 빌더의 프로퍼티를 의존하므로, 서비스 어플리케이션과 UI 빌더 사이에다가 위치시킴
manifest 에 블록의 스펙 선언 (프로퍼티)하고 builderConfig 에 주입함

고객이 자신의 문제를 해결 할 수 있는 길을 열어주자

미래의 고객이 무얼 원할지 알수 없다. 우리가 모든걸 해결할 수 없음
플러그인 생태계 구축
- 이를 통해서 변경을 밖에서 만들어 안으로 넣겠다는 의지