16화: Reacting to Input with State

이 글은 단순히 리액트 공식 문서를 읽고 베꼈을 뿐이다!! 학습 목적이라면 공식 문서를 보는 걸 추천한다.

 

참새. Unsplash 에 Patrice Bouchard 님이 올림

공식 문서

https://react.dev/learn/reacting-to-input-with-state

Reacting to Input with State – React

선언형 UI vs 명령형 UI

• UI 상호작용을 디자인할 때 우리는 보통 사용자의 행동에 따라서 UI가 어떻게 '바뀔지'를 생각함
• 선언형 프로그래밍에서는 우리 생각이랑 같은 방향━어떻게 '바뀔지'━으로 구현이 가능함 (결과)
• 명령형 프로그래밍에서는 UI를 '어떻게' 바꿀지를 알려줘야 함 (과정)
• 명령형 프로그래밍은 독립된/고립된 코드에서는 잘 작동하지만 복잡해질수록 버그에 노출될 위험이 있음
• 리액트는 선언형 UI 디자인을 지원

UI를 선언적으로 생각하는 법

1단계: 컴포넌트의 서로 다른 시각적 상태 구분하기

• 컴퓨터 과학에서 얘기하는 '상태 기계'처럼 UI 역시 여러 '시각적 상태'를 가질 수 있음
• 이용자가 볼 수 있는 UI의 모든 형태를 예상하기: 입력 전, 입력 중, 입력 완료, 제출 성공, 제출 실패, ...
• 스토리북 같은 도구를 이용하면 이런 형태를 쉽게 보여줄 수 있음

2단계: 무엇이 그 상태 변화를 유발하는지 결정하기

• 사람의 입력인가? (버튼, 글자 입력, 클릭, ...)
• 컴퓨터의 입력인가? (http response, promise resolve, timeout complete, ...)
• 어느 경우든 UI를 바꾸기 위해서는 상태 변수를 설정해야 함
• 사람의 입력은 이벤트 핸들러를 이용해야 하는 경우도 있음
• 순서도를 그려보는 것도 좋은 방법

3단계: 각 상태를 useState로 표현하기

• 일단 무조건 필요한 상태들 만들기
• 시각적 상태들 중 무엇을 보여줄 지 결정하는 상태들을 만들기
• 처음부터 잘 하려고 하지 말고 일단 만들어 보고 나중에 리팩터링하기

4단계: 불필요한 상태 없애기

• 이 상태가 역설적인 상황을 일으킬 수 있는가?: 두 boolean이 동시에 참일 수 없다면 두 상태를 합치는 것을 고려해 보기
• 다른 상태에서 같은 정보를 얻을 수 있는가?: 이름만 다를 뿐 두 상태가 완전히 연동된 것처럼 동작한다면 합치기
• 다른 상태의 역에서 같은 정보를 얻을 수 있는가?: error !== null이면 hasError === true처럼 되어 있다면 합치기
• 표현해야 할 상태들이 많고 불가능한 상태 조합을 없애기 힘들다면 reducer 활용해보기

5단계: 상태 변경을 위한 이벤트 핸들러 연결하기

여담) 어디까지 선언형일까?

어셈블리어는 명령형이다. 결국 모든 선언형 프로그래밍은 명령형 프로그래밍인 셈이 아닐까?
그렇다면 컴포넌트를 만들 때 어디까지 선언형으로 작성하는 게 맞을까?
우아한테크코스 미션의 프로그래밍 요구사항에는 이런 내용이 있다. '함수 또는 메서드의 길이가 10줄을 넘어가지 않도록 구현한다'. 이 제약의 의도는 하나의 함수가 하나의 역할을 하게끔 만들기 위함이다.
선언형 프로그래밍에서 하나의 선언은 곧 하나의 역할이라는 생각이 든다. 그렇다면 '정말 작은, 더 이상 쪼개기 힘든 하나의 기능'을 하는 친구만 명령형이고 나머지는 선언형으로 가는 게 맞나? 너무 어렵다..