고양이 사진첩 문제를 풀며 느낀점

화살표 함수의 한계점

처음 이 문제를 풀때, 컴포넌트를 화살표 함수로 표현했고 이들을 모듈로 관리했다. 하지만 아래와 같은 화살표 함수의 제한점들을 관과 했다.

• this나 super에 대한 바인딩이 없고, methods로 사용될 수 없다.
• new.target 키워드가 없다. (new로 생성된 시점을 파악한다.)
• 일반적으로 스코프를 지정할 때 사용하는 call, apply, bind methods를 사용할 수 없다.
• 생성자로 사용할 수 없다.
• yield를 화살표 함수 내에서 사용할 수 없다.

React에서는 컴포넌트 파일 안에 상태를 함께 관리했다. 컴포넌트에서 상태는 단순히 활용되는 데이터 이상의 의미를 갖는다.

선언적 프로그래밍과 컴포넌트 추상화

컴포넌트 형태로 추상화하는 것은 DOM 접근을 최소화하고 명령형 프로그래밍 보다는 선언적 프로그래밍을 하라는 의미이다.

명령형 프로그래밍과 선언적프로그래밍의 차이에 대한 내용은 아래 포스트에 따로 정리했다.

https://velog.io/@seyoung8239/Imperative-vs-Declarative-Programming

Imperative vs Declarative Programming

 

명령형으로 프로그래밍하면 DOM에 직접 접근하는 것에 제한과 규칙이 없으며, 재사용이 쉽지가 않아진다.

또한 DOM에 접근하고 업데이트하는 시점에 대한 명확한 기준이 없어, 코드가 거대해지고 UI의 업데이트가 잦아지는 경우 어느 지점, 어느 시점에 DOM을 업데이트 했느냐를 추척하기가 점점 어려워진다.

만약, 어떤 상태를 기준으로 렌더링하도록 만들어보면 어떨까?

 

선언적으로 설계한 컴포넌트에서 주목해야할 부분은 크게 3가지가 있다

• constructor - new 키워드를 통해 해당 컴포넌트가 생성되는 시점에 실행된다. 해당 컴포넌트가 표현될 el을 생성하고 파라미터로 받은 $app(DOM 변수)에 렌더링하도록 한다.
• render - 해당 컴포넌트의 state를 기준으로 렌더링한다. 자신의 상태를 기준으로 렌더링을해야하기 때문에, 별도의 파라미터를 받지 않아야 한다.
• setState - 해당 컴포넌트의 state를 갱신한다. render 함수가 별도의 파라미터 없이 자신의 상태를 기준으로 렌더링하도록 작성 되어 있기 때문에, state를 변경하고 다시 render 함수를 부르도록 함으로써 업데이트된 상태를 화면에 반영할 수 있게 된다.

이런 식으로 작성하면, 실제 DOM을 직접 제어하는 부분을 컴포넌트가 인스턴스화 하는 시점, 그리고 render함수가 다시 호출 되는 시점으로 제한할 수 있다.

컴포넌트간의 의존도 줄이기

앞서 작성한 컴포넌트는 단순히 상태를 기준으로 렌더링만 하고, 실제 UI 인터렉션에 따라 state를 변경해야하는 부분이 요구사항에 있다.

요구사항에 응하려면, Nodes에서 발생하는 인터랙션에 의해 Breadcrumb에도 영향을 주어야 한다.

 

이때, Nodes 코드 내에서 Breadcrumb를 직접 다루거나 업데이트 하도록 코드를 작성하면 Nodes 컴포넌트를 독립적으로 사용할 수 없게 된다. Breadcrumb에 의존성이 생기기 때문이다. Breadcrumb 없이 Nodes만 필요한 화면에서 재사용이 불가능해진다.

 

이런 경우 일반적으로 두 컴포넌트를 조율하는 더 상위의 컴포넌트를 만들고, 콜백 함수를 통해 느슨하게 결합한다.

이 때, App 컴포넌트에서 두 컴포넌트를 조율하게 되며, 두 컴포넌트는 독립적으로 동작하고 또 다른 곳에 쉽게 재사용할 수 있는 구조가 된다.