React + Ts 프론트엔드 개발기(feat. 메이플스토리) - 02. 클라이언트단 데이터 흐름

1. 서버로부터 받아오는 데이터 흐름

- UI는 서버로 데이터 요청

- 응답으로 받은 데이터 저장

- 받은 데이터는 UI 렌더링을 위해 적합한 구조 혹은 값으로의 형태 변환이 필요

- 형태가 변환된 데이터를 바탕으로 UI 그리기

UI를 출력하는 부분은 전적으로 가공된 데이터에만 의존해, 다른 흐름으로부터의 개입이 없어 복잡도를 낮출 수 있습니다.

 

 

2. 유저 인터랙션에 의한 데이터 수정과 리렌더링

 

 - UI는 유저 인터랙션에 의해 데이터를 수정

 - 데이터 값의 변경에 따라 출력을 위해 가공된 데이터의 형태도 따라 변경

 - 변경된 가공된 데이터를 통해 UI의 리렌더링 발생

서버 요청/응답에서와 마찬가지로, 단방향 데이터 흐름을 유지할 수 있습니다.

 

3. 데이터를 활용한 서버 요청 (검색 등)

 - 인풋에 값을 입력하는 등의 행위를 통해 데이터의 값을 변경

 - 엔터, 검색버튼 클릭 등을 통해 서버로의 요청

 - 이 때, input.value에 직접 접근하는 식이 아닌, input에 값을 입력하며 변경된 입력값을 저장하고 있는 데이터의 값을 바탕으로 서버에 요청

서버로 요청하기 위해 필요한 값을 가져오기 위해, 산발적으로 위치한 DOM에 직접 접근하는 것이 아닌, 현재의 상태에서 저장되어 있는 '데이터' 에만 접근해 값을 취하도록하여 복잡도를 낮출 수 있습니다.

 

- UI 렌더링을 위한 단방향 데이터 흐름,

- 각 페이지마다 다른 종류의 인풋이 있을텐데, 각 인풋의 DOM과 직접적인 결합도를 가지지 않고 한 층 추상화된 레이어를 활용해 복잡도 감소

 

 

 - 데이터 가공 방식에 변화를 줄 수 있는 사용자 개인 설정을 제공하지 않고, 고정된 방식만을 활용할 것이기에 위와 같은 방식을 채택했습니다.

 - 글을 작성하면서도 생각되는 부분이, 생각보다 받아온 데이터를 가공할 일이 많을까? 그렇다면 가공된 데이터를 또 따로 저장해두고 여러군데서 가져다 쓸 상황이 많을까? 가공이 필요하지 않은 데이터가 많아 "데이터"와 "가공된 데이터"의 형태 차이가 거의 없어 "데이터"를 그냥 복사해 하나 더 가지고 있는 경우만 생기는 것은 아닐까? 하는 생각이 듭니다.

 - 위 생각들을 바탕으로 내린 결론에 가공된 데이터 부분은 크게 고려될 것 같지 않으나 이 또한 고민한 흔적이기에 본문은 수정 않고 그대로 남겨봅니다,,