상태 관리란?

상태 관리란??

전단 부근에서 상당히 빈번하게 날아다니는 단어인'컨디션 관리'.
하지만 컨디션 관리는 무엇입니까?솔직히 "전혀 모른다"는 사람이 많을 거예요.
컨디션 관리는 전단 특유의 특수한 상황에서 만들어진 어휘로, 디자인론의 주제이기 때문에 전단 초보자, 특히 초보 엔지니어들에게 파악하기 어려운 인상을 남겼다.
이번에는 이들에게'컨디션 관리'를 간단명료하게 설명하고 싶다.
플렉스, 레드룩스, 리액트 훅스 등 컨디션 관리 기법은 언급하지 않는다.
차라리 "왜 앞부분에 이런 도구가 필요합니까?"이 점에서 앞의 엔지니어 초보자와 앞의 엔지니어 이외의 사람들도 읽을 수 있는 내용에 초점을 맞추는 것이 목표다.

독자 대상

상태 관리라고 불리며 이해할 수 없는 엔지니어

TL,DR

'상태 관리'는 SPA 개발에서 무상태로 UI를 설치할 때 반드시 발생하는'그러면 어디서, 어떻게 상태를 유지할까요?'라는 주제를 담았다.(결국 필자의 해석일 뿐.)

SPA 개발의 복잡성은 "상태"에서 발생합니다.

기존의 프런트엔드 메인스트림은 데이터를 정적 HTML로 변환하는 "단순한 작업"

옛날에 View의 구축은 일반적으로 템플릿 엔진(jsp, Blade 등)의 기술을 사용했다.
그들의 업무는 제공된 데이터와 조건의 불일치를 반복해서 변수로 채워서 HTML로 바꾸는 것이다.

@foreach($users as $user)
<div>
  {{$user->getUsername()}}
<div>
@endforeach

상기 Blade(Laavel)의 예에 따라 $user를 매개 변수@foreach로 회전시키고 {{}}에 변수를 삽입하여 UI를 구축한다.
간단하네.(각 백엔드의 MVC 프레임워크에 대해 서로 다른 템플릿 엔진의 기록 방법을 배워야 하는 문제 제외)
UI 구축은 데이터와 템플릿을 입력하여 HTML을 출력하는 함수 처리만 하면 되기 때문이다.

UI의 SPA를 사용자의 브라우저에서 동적으로 계속 변경

그렇다면 최근 프런트엔드 개발의 트렌드는 SPA(한 페이지 애플리케이션)다.
이는 기존의 기능성 UI 구축과 달리 사용자 브라우저의 UI 동적 변화가 지속되는'UI 변화'문제로 개발자가 직면하게 된다.
예를 들어, UI 마이그레이션은 다음과 같은 경우에 발생합니다.

비동기식 서버 데이터

표의 실시간 검증

페이지 내 레이블 전환

UI 의 변경 사항으로 인해 복잡성이 발생하는 이유는 무엇입니까?

그렇다면 UI의 지속적인 동적 변화는 왜 복잡해질까.
UI를 변경하려면 이전 DOM 상태에서 계속 손을 포함해야 하기 때문입니다.
예를 들어 바닐라 JS에서 서버에서 비동기적으로 데이터를 가져와 표시하는 샘플 설치를 살펴보자.

// APIからデータを取ってくる
const getTodoList = async () => {
  return ["遊ぶ", "買い物", "宿題"];
};

const container = document.getElementById("todo-list");

// ローディング画面を表示
const loading = document.createElement("div");
loading.textContent = "loading";
container.appendChild(loading);

getTodoList().then(todoList => {

  // ローディング画面を削除
  container.removeChild(loading);

  todoList.forEach(todo => {
    const dom = document.createElement("li");
    dom.textContent = todo;
    container.appendChild(dom);
  });
});

번거로운 것은 마운트 화면에서 실제 TODO 목록을 표시할 때 마운트 화면을 삭제해야 한다는 것이다.또한<div id="todo-list" />에 TOD 목록이 표시되었지만<div id="todo-list" />DOM에 대한 보증은 없었다.SPA 개발의 전제 조건은 UI가 많은 비동기식 프로세스로 인해 순식간에 변화하는 경우가 많기 때문이다.
이전 DOM에 계속 손을 포함하는 상태에서는 DOM의 더하기와 빼기가 적용됩니다.UI와 논리가 밀접하게 결합된 상태입니다.
JQuery와 같은 단순한 DOM 조작 조수를 사용하는 것도 마찬가지다.

표지에서 복잡도를 완전히 분리하는 데 성공했다

이 복잡성을 해결한 것은 React입니다.
React는 개념적으로Declaitive(선언적),https://reactjs.org/）
UI 구축은 다음 예에서 데이터를 HTML로 변환하는 함수로 수행할 수 있습니다.

// APIからデータを取ってくる
const getTodoList = async () => {
  return ["遊ぶ", "買い物", "宿題"];
};

// カスタムフック
const useTodoList = () => {
  const [state, setState] = React.useState<string[] | null>(null);
  React.useEffect(() => {
    getTodoList().then(todoList => {
      setState(todoList);
    });
  }, []);
  return state;
};

function App() {
  const state = useTodoList();
  // データがまだ取得できていないならローディング、取得できているならそれを表示する関数
  return <ul>{state ? state.map(e => <li>{e}</li>) : "Loding"}</ul>;
}

선언적인 UI 구축?

React에서 보여준 UI 빌드의 선언성은 무엇입니까?위에서 설명한 대로 데이터를 HTML로 변환하는 함수로 해석할 수 있습니다.
즉, 태그를 지정할 때 매개 변수가 제공하는 현재 데이터를 HTML로 어떻게 표현할 것인가.'UI의 변화'에만 집중하면 DOM이 과거에 어떤 상태였는지 신경 쓸 필요가 없다.

문제는 UI의 변천에서 데이터의 변천으로 바뀌었다.그리고'상태 관리'라는 단어가 돼요.

UI의 변경 사항에서 태그를 분리하면 더욱 간단해집니다.
그러나 이것은'표시'에서'상태'를 분리하는 것일 뿐 전단은'상태'에서 해방되지 않는다.데이터의 변화는 여전히 사람을 괴롭게 한다.
전단의 가장자리는'상태 관리'라는 단어를 주제로 하고 플렉스와 Redux 등 상태 관리 도구를 탄생시켰다.

상태 관리의 의미

물론'컨디션 관리'라는 단어를 몰라도 컨디션 관리 라이브러리에 넣지 않고도 리액트와 뷰로 개발할 수 있다.
그러나 다인 규모의 개발로 앱에 일관된 상태 관리 지침이 없다면 개발자는'상태 관리'에 대해 1부터 머리를 안는다
완성된 소스 코드는 상태 코드와 태그 코드가 혼합된 모든 내용을 보기 어려울 것이다.
반대로, 만약 당신이 당신의 상태를 완벽하게 관리할 수 있다면, 사용자와 도메인 이름의 교류를 마음대로 제어할 수 있을 것이다.
상태가 응용 프로그램에서 사용자가 얻는 정보의'원천'이기 때문에 사용자에게는 유일한 진실(Single source of truth)이다.