왜 이렇게 궁금합니까?JavaScript 프레임워크의 비동기식 일관성 이해

최근에 어떤 사람이 나를 찾아와서 나에게 "일반적인 의미의 궁금증은 무엇입니까?"라고 물었다.그들은 자원 React 개만 찾을 수 있다고 말했다.나는 그들에게 그들이 이 단어를 창조한 것은 일리가 있다고 말했다.그러나 사방을 둘러보니 그뿐만이 아니라는 것을 깨달았다.
대부분의 글에서 설명된 주제를 보았을 때, 그것은 그것이 도대체 무엇인가가 아니라 궁금증 성분의 증상을 이야기했다.그래서 오늘 나는 왜 그것이 단지 자리 차지 문자를 나타내는 구성 요소만이 아닌지를 보여 주려고 한다.

사용자 인터페이스의 일관성

일치된 정보 표시는 양호한 사용자 인터페이스의 기본 요구이다.같은 페이지에서 사용자에게 일치하지 않는 정보를 표시하면 신뢰가 약해집니다.

From Michel Westrate's Becoming Fully Reactive: An in-depth explanation of MobX

만약 당신의 사진이 한 곳에서 갱신된 것이지 다른 곳에서 갱신된 것이 아니라면, 당신은 당신이 읽고 있는 것이 최신이라고 믿을 수 있습니까?만일을 대비해서 브라우저 페이지를 다시 불러오려고 시도할 수도 있습니다.만약 댓글 수량이 당신이 본 댓글 수량과 일치하지 않는다면, 설령 수량이 적다 하더라도, 당신은 당신이 무엇을 빠뜨렸다고 생각할 수도 있습니다.하지만 더 많은 문제가 있다. 그것은 제품의 가격과 일치하지 않는가?
이것은 네가 볼 수 있는 범위를 넘어섰다.만약 웹 응용 프로그램의 내부 상태가 최종 사용자에게 표시된 내용과 일치하지 않는다면, 무슨 일이 일어날까요?이것은 그들이 원래 하지 않았던 결정을 내리게 할 수 있습니까?중요한 결정?만약 네가 그들에게 한 가지 일을 보여주고 다른 일을 한다면, 그들은 이 점을 의식하지 않을까?
물론 인터넷상에서 우리는 우리가 본 것이 최신이 아닐 수도 있다는 사실에 익숙해졌다.백엔드의 현재 상태에 비해 회선을 통해 보내는 것은 항상 지연됩니다.비록 이것은 일이 지나갈 수도 있고, 우리가 제기한 일부 요청이 거절될 수도 있지만, 일치하지 않는 인터페이스는 우리를 이러한 상황에 빠지게 할 수도 있다. 응용 프로그램은 자신이 옳은 일을 했다고 생각하고 검증을 통과했지만, 최종 사용자만 이 점을 의식하지 못할 것이다.
다행히도, 우리는 이를 위해 전문적으로 설계한 도구가 있다.일반적으로 현대 UI 라이브러리와 프레임워크는 일관성을 고려합니다.

프레임 일관성

가장 간단한 일치성 형식은 파생 상태와 원본 상태가 동기화되는 것을 확보하는 것이다.예를 들어 만약 당신이 주count를 가지고 있다면 주doubleCount는 사실상 항상 이 숫자의 두 배이다.반응식 라이브러리에서, 우리는 통상적으로 그것을 glitch-free 집행이라고 부른다.그것은 이렇게 보일 수도 있다.

const [count, setCount] = useState(1);
const doubleCount = useMemo(() => count * 2, [count]);

서로 다른 틀은 서로 다른 방식으로 이런 관계를 확보한다.React에서는 상태 업데이트가 에 즉시 적용되지 않으므로 React 상태가 모두 적용될 때까지 이전 상태를 계속 볼 수 있습니다.Vue나Solid와 같은 반응식 라이브러리는 업데이트된 다음 줄에서 원본 데이터뿐만 아니라 모든 파생 데이터도 업데이트하기 위해 더욱 적극적으로 업데이트하는 경향이 있다.

// React
setCount(20);
console.log(count, doubleCount); // 1, 2

// Solid
setCount(20);
console.log(count, doubleCount); // 20, 40

이런 상황에서 차이는 중요하지 않다. 왜냐하면 이 두 가지 상황에서 그것들은 일치하기 때문이다.결국 비슷한 결과를 얻었다.외부에서 볼 때 상태 갱신은 원자이며 모든 곳에 적용된다.

비동기식 일관성

문제는 무고장 라이브러리에 대해 현재 업데이트든 나중에 업데이트든 동기화해서 적용된다는 점이다.모든 업데이트는 같은 기호를 가지고 있으며, 서로를 볼 수 있다.이것은 일치성을 확보하는 데 매우 중요하다.그러나 모든 것이 동기화되지 않으면 무슨 일이 일어날까?
이것은 상당히 어려운 문제로 많은 학술 논문들이 이 문제를 주제로 한다.심지어 자바스크립트 생태계와 관련된 것, 예를 들면this paper on Elm from 2013.그러나 이 문제를 설명하기 위해서 저희count와 doubleCount를 다시 한 번 고려해 주십시오. 그러나 만약에 저희가 서버에 가서 계산해야 한다doubleCount.

// Not real React code, just for illustrative purposes
const [count, setCount] = useState(1);
const doubleCount = useMemo(async () =>
  await fetchDoubleCount(count)
  , [count]
);

// somewhere else:
setCount(20);

현재, 우리 count 는 1부터 시작하고, doubleCount 는 처음에 정의되지 않았습니다. 왜냐하면 이것은 우리가 잡고 있기 때문에 일치하지 않는 상태에 있기 때문입니다.나중에 어느 순간에, 그것이 해결될 때 doubleCount 는 2가 될 것이며, 우리는 다시 한 번 일치할 것이다.우리가 count를 20으로 설정하면 이런 상황이 발생한다.doubleCount는 40에 안정될 때까지 1의 값이 될 것이다.useEffect에 로그인한 경우 다음을 볼 수 있습니다.

1, undefined
1, 2
20, 1
20, 40

이것은 결코 의외가 아니지만 결코 일치하지 않는다.문제는 바로 여기에 있다.3가지 가능한 결과만 우리 사용자가 이러한 불일치 상태를 보지 못하게 할 수 있다.

1. 곤란 해소

일치하지 않는 상태가 아니라 뭔가를 보여줘.최종 사용자에게 불일치성을 숨기고 디스플레이가 준비될 때까지 백엔드에서 일을 해결합니다.

2. 과거에 머물다

새 컨텐트가 표시될 준비가 될 때까지 변경 내용을 적용하지 않고 그대로 표시합니다.

3. 미래 예측

비동기 상태에서 업데이트할 때 변경 사항을 즉시 적용하고 미래 값을 표시한 다음 업데이트가 끝났을 때 변경합니다. (그러나 이것은 이미 같을 것입니다.)
보편적인 해결 방안으로서 첫 번째는 비교적 쉽다.우리는 줄곧 이렇게 했다.우리는 업데이트된 내용을 표시할 준비가 될 때까지 원본 코드 변경을 즉시 적용한 다음 마운트 표시기를 표시할 수 있습니다.많은 사람들과 도서관이 궁금증을 보고 거기에 멈추었다.
하지만 우리가 더 하고 싶다면요?내용을 삭제하고 일정 시간 후에 교체하는 것은 상당히 불협화적인 사용자 체험일 수 있다.나는 우리 모두가 미래에 살고 싶어 한다고 생각한다. 그러나 이것은 사용자가 변이를 실행하고 있지 않으면 어느 정도 비현실적이다.이러한'낙관적인 업데이트'는 좋은 도구이지만 완벽하지도 않고 항상 적용되지도 않는다.만약 당신이 단지 최신 데이터를 얻고 싶을 뿐이라면, 당신은 아직 받지 못한 데이터를 얻지 못할 것이다.

우리 과거로 돌아가자.까다로운 부분은 데이터 변경을 적용하지 않으면, 우리는 어떻게 다가오는 비동기 요청을 촉발합니까?
좋아, 우리는 우리가 미래에 갱신하기를 희망하는 상태를 복제할 수 있다.우리가 count와 futureCount를 doubleCount에서 파생시킬 수 있는 것처럼 모든 문제가 해결된 후에만 futureCount의 값을 futureCount에 적용할 수 있다.하지만 까다롭다.하나 이상의 물건을 얻는 것과 여러 개의 다른 출처가 있다면.우리는 이 변화의 하류에 있는 모든 것을 복제해야 한다.
Transitions 또는 React 중의 Solid 많든 적든 이렇게 하는 것이다.동시에 나타나는 존재로 인해 응용 프로그램은 하나의 상태를 유지할 수 있고, 우리는 안전하게 새로운 업데이트 현실을 나타낼 수 있으며, 모든 것이 해결된 후에만 이러한 변경 사항을 제출할 수 있다.이것은 우리가 준비를 하기 전에 과거의 일치성을 유지하는 체계적인 방식이다.
왜 병발이죠?UI가 최종 사용자에게 계속 표시되므로 UI가 완전히 중단되는 것을 원치 않습니다.예를 들어 애니메이션과 다른 비파괴적인 상호작용.이것은 최종적으로 변화를 조율하기 위해 더 많은 작업이 필요하지만, 최종적으로는 최종 사용자 체험 기능이다.

이 모든 것을 함께 놓아라

갑작스런 결정Reactcount은 과거에 머무르는 것이 심상치 않아 보였다.비동기 파생 상태를 하향 조정할 수 있는 것을 모르기 때문에 알기 전에 업데이트를 피해야 합니다.같은 이유로 이 프레임워크들은 현시적으로 선택하고 렌더링할 수 있다는 것이다.
구성 요소를 만들어서 상태를 만들고 업데이트하는 것을 상상하십시오.만약 어떤 수신 도구의 하위 구성 요소가 격리 및 전환 중의 상태 변경을 책임진다면, 이것은 매우 심상치 않을 것이다.이런 행위는 가입을 선택해야 한다.
마찬가지로 탈퇴를 선택할 수 있는 것도 중요하다.때로는 어느 정도의 불일치가 필요할 때도 있고, 심지어는 취할 수도 있다.예를 들어 가능한 한 빨리 데이터를 볼 필요가 있다면.
요컨대 궁금증과 과도는 사용자 인터페이스의 일치성 문제를 해결하는 데 매우 유용한 도구를 제공했다.이것은 최종 사용자에게 있어서 큰 장점이다.이것은 성능과 무관하다.이것은 단지 데이터 획득만이 아니다.이것은 사용자가 신뢰할 수 있는 UI를 쉽게 만들고 예상한 방식으로 조작하며 사용자가 웹 응용 프로그램을 어떻게 찾든지 원활한 체험을 제공하기 위해서입니다.