React 처럼 사고하기

eeensu·2023년 8월 6일
0

React 기본

목록 보기
19/22
post-thumbnail

React의 개발자가 할일

react 개발자가 React처럼 사고하는 것은 코드를 효율적으로 작성하고 유지 관리하기 위해 중요하다. 또한 react의 흐름을 이해하고 이를 잘 분석하여 react의 목적과 의의에 맞는 최적화된 웹 개발에 방향성을 맞출 수 있기 때문이다.

그렇다면 근본적으로, react를 활용하여 웹의 프론트를 개발하고자 할 때, 어디서부터 시작해야하며, 어떠한 방법으로 구성하고, 조립하고, 이를 어떻게 수정해야하는 것일까? react를 개발할 때는 다음과 같은 단계를 거쳐 제작하는 것을 추천한다.



1단계 - UI를 component 계층 구조로 나누기

모든 태그를 컴포넌트로 구조화 하고, 각각의 이름을 붙이는 것이다. 어떤 엘리먼트가 컴포넌트가 되어야 할지 모르겠다면, 우리가 새로운 함수나 객체를 만들 때처럼 생각하면 된다. 한 가지 테크닉은 단일 책임 원칙이다. 이는 하나의 컴포넌트는 한 가지 일을 하는게 이상적이라는 원칙이다. 하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 하는것도 좋은 방법이다.

대부분의 웹사이트는 프론트단으로만 이루어지지 않는다. 웹 서버와 상호작용하여 fecth한 JSON 데이터를 바탕으로 유저에게 화면을 보여준다. 때문에 데이터 모델이 적절하게 만들어졌다면, UI를 잘 연결하는 것도 무리가 없을 것이다. 중요한 것은, 각 컴포넌트가 데이터 모델의 한 조각을 표현하도록 개발자는 유도하듯이 컴포넌트를 만들어야 한다는 점이다.




2단계 - React로 정적인 버전 만들기

데이터 모델들을 가지고 (혹은 더미 데이터) 렌더링은 되지만 아무 동작도 없는 버전을 만들어 보는 것이다. 이처럼 과정을 나누는 것이 좋은 이유는 정적 버전을 만드는 것은 생각은 적게 필요하지만 타이핑이 많이 필요로 하고, 상호작용을 만드는 것은 생각을 많이 해야하지만 타이핑은 적게 필요로 하기에 두가지 과정을 거치면 어떤 상황이 일어나도 유연하게 대처할 수 있는 능력이 향상되기 때문이다.

다른 컴포넌트를 재사용하는 컴포넌트로 만들고 props를 이용해 데이터를 전달해 주자. 이 때, state를 사용하지 않는 것이 좋다. state는 오직 상호작용을 위해, 즉 시간이 지남에 따라 데이터가 바뀌는 것에 사용해야 한다.

또한 앱을 만들 때, 하향식이나 상향식으로 만들 수 있다. 다시 말해 계층 구조의 상층부에 있는 <Container></Container> 컴포넌트 부터 만들거나 하층부에 있는 <li></li> 부터 만들거나 두 가지 방법으로 할 수 있다. 간단한 예시에서는 보통 하향식으로 만드는게 쉽지만 프로젝트 규모가 커지면 상향식으로 만들고 테스트를 작성하면서 개발하기가 더 쉽다.

이 단계가 끝나면 데이터 렌더링을 위해 만들어진 재사용 가능한 컴포넌트들의 소규모 라이브러리를 가지게 된다.





3단계 - UI state에 대한 최소한의 (하지만 완전한) 표현 찾아 내기

UI를 상호작용하게 만들려면 데이터 모델을 변경할 수 있는 방법이 있어야 한다. 이를 react 에서는 state를 통해 변경한다. 애플리케이션을 올바르게 만들기 위해서는 애플리케이션에서 필요로 하는 변경 가능한 state의 최소 집합을 생각해보아야 한다.

여기서 핵심은 중복 배제 원칙이다. 애플리케이션이 필요로 하는 가장 최소한의 state를 찾고 이를 통해 나머지 모든 것들이 필요로 하는 가장 최소한의 state를 찾고, 이를 통해 나머지 모든 것들이 필요에 따라 그때그때 계산되도록 만들어야 한다.

예를 들어 Todo 리스트를 만든다고 하면, Todo 아이템을 저장하는 배열만 유지하고 Todo 아이템의 개수를 표현하는 state를 별도로 만들면 안된다. 아이템의 개수는 배열에서 간단히 가져올 수 있기 때문이고, 이를 활용하지 않으면 메모리 낭비이기 때문이다.


그렇다면 컴포넌트에서 이 기능이 state 필요 여버룰 어떻게 판단할까? 다음의 적합한 조건이 있다.

  1. 부모로부터 props를 통해 전달받지 않았는가?
    ===> state O
  2. 시간의 흐름과 이벤트의 발생으로 인해 변경될 수 있는가?
    ===> state O
  3. 컴포넌트 안의 또다른 state나 props를 가지고 계산이 가능한가?
    ===> state x

예시를 통해 생각해 보자. 다음과 같은 데이터가 있다.

1. 제품의 원본 목록
2. 유저가 입력한 검색어
3. 체크박스의 값
4. 필터링된 제품의 목록

  1. --> 제품의 원본 목록은 props를 통해 전달되므로 state가 아니다.
  2. --> 검색어는 user의 입력에 따라 달라지기에 state로 볼 수 있다.
  3. --> 체크박스는 user 의 입력을 받아 달라지기에 state로 볼 수 있다.
  4. --> 필터링된 제품의 목록은 state가 아니다. 제품의 원본 목록과 검색어, 체크박스의 값을 조합해서 계속해낼 수 있기 때문이다.




4단계 - state가 어디에 있어야 할 지 찾기

react는 항상 컴포넌트 게층 구조를 따라 아래로 내려가는 단방향 데이터 흐름을 따른다. 어떤 컴포넌트가 어떤 state를 가져야하는지에 대한 결정은 다음 아래의 방법이 도움이 될 수 있다.

  • state를 기반으로 하는 모든 컴포넌트를 찾는다.

  • 계층 구조 내에서 특정 state가 있어야 하는 모든 컴포넌트들의 상위에 있는 하나의 부모 컴포넌트를 찾는다.

  • 공통 혹은 더 상위에 있는 컴포넌트가 state를 가져야 한다. 형제가 형제에게 state를 넘겨주는 것은 어렵기 때문이다.

  • state를 소유할 적절한 컴포넌트를 찾지 못했다면 state를 소유하는 컴포넌트를 하나 만들어서 공통 오너 컴포넌트의 상위 계층에 추가한다.





5단계 - 역방향 데이터 흐름 추가하기

계속 부모에서부터 자식으로 (위에서 아래로) state를 내려주었다면, 역으로 자식이 부모의 state를 바꾸는 상황이 올 수 있다. 이 상황을 고려하여 다양한 방식의 코딩을 해야 더욱 더 유연하고 효과적인 개발이 가능하다.




마지막으로, react처럼 사고하는 것은 단순히 react 웹 애플리케이션을 개발하는 데만 중요한 것이 아니다. 이러한 사고 방식은 더 큰 규모의 프로젝트나 다른 프레임워크 및 라이브러리를 사용할 때에도 유용하며, 좀 더 모듈화되고 효율적인 코드를 작성하는 데 도움이 된다.
react가 기존의 프론트엔드 프로그래밍을 대체하였듯이, 언젠간 react를 대체하는 오버 테크놀러지가 유행할 수 있다. 이를 잘 유념해야 한다.

[출처]

profile
안녕하세요! 26살 프론트엔드 개발자입니다! (2024/03 ~)

0개의 댓글