React: React.memo 및 useContext 훅으로 재렌더링 방지.

이것은 설계된 대로 작동합니다. 궁금한 점이 있으면 https://github.com/facebook/react/issues/14110 에 이에 대한 더 긴 토론이 있습니다.

어떤 이유로 값에 theme 속성이 있는 AppContext 가 있고 appContextValue.theme 변경 시 일부 ExpensiveTree 만 다시 렌더링하려고 한다고 가정해 보겠습니다.

TLDR은 현재로서는 세 가지 옵션이 있다는 것입니다.

옵션 1(선호): 함께 변경되지 않는 분할 컨텍스트

많은 구성 요소에서 appContextValue.theme 가 필요하지만 appContextValue 자체가 너무 자주 변경되는 경우 ThemeContext 에서 AppContext ThemeContext 를 분할할 수 있습니다.

function Button() {
  let theme = useContext(ThemeContext);
  // The rest of your rendering logic
  return <ExpensiveTree className={theme} />;
}

이제 AppContext 변경해도 ThemeContext 소비자를 다시 렌더링하지 않습니다.

이것은 선호되는 수정 사항입니다. 그러면 특별한 구제금융이 필요하지 않습니다.

옵션 2: 구성 요소를 둘로 나누고 그 사이에 memo 를 넣습니다.

어떤 이유로 컨텍스트를 분할할 수 없는 경우에도 구성 요소를 둘로 분할하고 내부 구성 요소에 보다 구체적인 props를 전달하여 렌더링을 최적화할 수 있습니다. 당신은 여전히 ​​바깥 쪽을 렌더링하지만 아무 것도하지 않기 때문에 저렴해야합니다.

function Button() {
  let appContextValue = useContext(AppContext);
  let theme = appContextValue.theme; // Your "selector"
  return <ThemedButton theme={theme} />
}

const ThemedButton = memo(({ theme }) => {
  // The rest of your rendering logic
  return <ExpensiveTree className={theme} />;
});

옵션 3: 내부에 useMemo 구성요소 1개

마지막으로 코드를 좀 더 장황하게 만들 수 있지만 반환 값을 useMemo 로 래핑하고 종속성을 지정하여 단일 구성 요소에 유지할 수 있습니다. 컴포넌트는 여전히 재실행되지만 모든 useMemo 입력이 동일한 경우 React는 자식 트리를 다시 렌더링하지 않습니다.

function Button() {
  let appContextValue = useContext(AppContext);
  let theme = appContextValue.theme; // Your "selector"

  return useMemo(() => {
    // The rest of your rendering logic
    return <ExpensiveTree className={theme} />;
  }, [theme])
}

앞으로 더 많은 솔루션이 있을 수 있지만 이것이 현재 우리가 가지고 있는 것입니다.

그래도 옵션 1이 더 좋습니다. 일부 컨텍스트가 너무 자주 변경되면 분할하는 것이 좋습니다.

테마가 변경되지 않은 경우 이 두 옵션 모두 자식 렌더링에서 제외됩니다.

@gaearon 버튼이 자식입니까 아니면 버튼이 자식을 렌더링합니까? 이것들이 어떻게 사용되는지 컨텍스트가 누락되었습니다.

unstable_Profiler 옵션 2를 사용하면 여전히 onRender 콜백을 트리거하지만 실제 렌더링 로직은 호출하지 않습니다. 내가 뭔가 잘못하고 있는 건 아닐까? ~ https://codesandbox.io/s/kxz4o2oyoo~ https://codesandbox.io/s/00yn9yqzjw

예제를 더 명확하게 업데이트했습니다.

불안정한_프로파일러 옵션 2를 사용하면 여전히 onRender 콜백을 트리거하지만 실제 렌더링 로직은 호출하지 않습니다. 내가 뭔가 잘못하고 있는 건 아닐까? https://codesandbox.io/s/kxz4o2oyoo

그것이 바로 그 옵션의 요점입니다. :-)

아마도 이에 대한 좋은 해결책은 주어진 콜백이 true를 반환하는 경우에만 컨텍스트를 "가져가" 구성 요소를 다시 렌더링할 수 있는 가능성을 갖는 것입니다. 예:
useContext(ThemeContext, (contextData => contextData.someArray.length !== 0 ));

실제로 만난 후크의 주요 문제는 후크 내부에서 구성 요소가 반환하는 것을 관리할 수 없다는 것입니다. 렌더링을 방지하고 메모화된 값을 반환하는 등입니다.

우리가 할 수 있다면, 그것은 구성할 수 없을 것입니다.

https://overreacted.io/why-isnt-xa-hook/#not -a-hook-usebailout

옵션 4: 데이터 전파에 컨텍스트를 사용하지 말고 데이터 구독을 사용하십시오. useSubscription을 사용하십시오(모든 경우를 커버하기 위해 작성하기 어렵기 때문에).

다시 렌더링을 방지하는 또 다른 방법이 있습니다.
"재렌더링 구성 요소에서 JSX를 한 단계 위로 이동해야 합니다. 그러면 매번 다시 생성되지 않습니다."

자세한 정보는 여기

아마도 이에 대한 좋은 해결책은 주어진 콜백이 true를 반환하는 경우에만 컨텍스트를 "가져가" 구성 요소를 다시 렌더링할 수 있는 가능성을 갖는 것입니다. 예:
useContext(ThemeContext, (contextData => contextData.someArray.length !== 0 ));

실제로 만난 후크의 주요 문제는 후크 내부에서 구성 요소가 반환하는 것을 관리할 수 없다는 것입니다. 렌더링을 방지하고 메모화된 값을 반환하는 등입니다.

여기에서 참/거짓 대신... 컨텍스트에서 데이터를 부분집합할 수 있는 ID 기반 기능을 제공할 수 있습니까?

const contextDataINeed = useContext(ContextObj, (state) => state['keyICareAbout'])

여기서 useContext는 선택기 fn의 결과가 동일한 함수의 이전 결과와 동일하지 않는 한 이 구성 요소에서 팝업되지 않습니다.

이 라이브러리는 Facebook이 후크와 통합하는 솔루션일 수 있음을 발견했습니다. https://blog.axlight.com/posts/super-performant-global-state-with-react-context-and-hooks/

다시 렌더링을 방지하는 또 다른 방법이 있습니다.
"재렌더링 구성 요소에서 JSX를 한 단계 위로 이동해야 합니다. 그러면 매번 다시 생성되지 않습니다."

자세한 정보는 여기

문제는 위에서 아래로 다시 렌더링되는 것을 방지하기 위해 구성 요소 트리를 재구성하는 데 비용이 많이 들 수 있다는 것입니다.

@fuleinist 특정 사용 사례에 대해 많이 단순화되었지만 궁극적으로 MobX와 크게 다르지 않습니다. MobX는 이미 이와 같이 작동하고(프록시도 사용) 상태가 변경되고 상태의 특정 비트를 사용하는 구성 요소가 다시 렌더링됩니다.

@gaearon 내가 뭔가를 놓치고 있는지 모르겠지만 두 번째 및 세 번째 옵션을 시도했지만 올바르게 작동하지 않습니다. 이것이 크롬 확장 버그에 반응하는지 아니면 다른 캐치가 있는지 확실하지 않습니다. 다음은 두 입력을 모두 다시 렌더링하는 형식의 간단한 예입니다. 콘솔에서 메모는 작업을 수행하지만 DOM은 항상 다시 렌더링되는 것을 볼 수 있습니다. 1000개 항목을 시도했는데 onChange 이벤트가 정말 느려서 memo()가 컨텍스트와 올바르게 작동하지 않는다고 생각합니다. 조언 감사합니다:

다음은 1000개 항목/텍스트 상자가 있는 데모입니다. 그러나 그 데모에서 개발 도구는 다시 렌더링을 표시하지 않습니다. 테스트하려면 로컬에서 소스를 다운로드해야 합니다. https://codesandbox.io/embed/zen-firefly-d5bxk

import React, { createContext, useState, useContext, memo } from "react";

const FormContext = createContext();

const FormProvider = ({ initialValues, children }) => {
  const [values, setValues] = useState(initialValues);

  const value = {
    values,
    setValues
  };

  return <FormContext.Provider value={value}>{children}</FormContext.Provider>;
};

const TextField = memo(
  ({ name, value, setValues }) => {
    console.log(name);
    return (
      <input
        type="text"
        value={value}
        onChange={e => {
          e.persist();
          setValues(prev => ({
            ...prev,
            [name]: e.target.value
          }));
        }}
      />
    );
  },
  (prev, next) => prev.value === next.value
);

const Field = ({ name }) => {
  const { values, setValues } = useContext(FormContext);

  const value = values[name];

  return <TextField name={name} value={value} setValues={setValues} />;
};

const App = () => (
  <FormProvider initialValues={{ firstName: "Marr", lastName: "Keri" }}>
    First name: <Field name="firstName" />
    <br />
    Last name: <Field name="lastName" />
  </FormProvider>
);

export default App;

반면에 컨텍스트가 없는 이 접근 방식은 올바르게 작동하지만 디버그에서는 여전히 예상보다 느리지만 적어도 다시 렌더링하는 것은 괜찮습니다.

import React, { useState, memo } from "react";
import ReactDOM from "react-dom";

const arr = [...Array(1000).keys()];

const TextField = memo(
  ({ index, value, onChange }) => (
    <input
      type="text"
      value={value}
      onChange={e => {
        console.log(index);
        onChange(index, e.target.value);
      }}
    />
  ),
  (prev, next) => prev.value === next.value
);

const App = () => {
  const [state, setState] = useState(arr.map(x => ({ name: x })));

  const onChange = (index, value) =>
    setState(prev => {
      return prev.map((item, i) => {
        if (i === index) return { name: value };

        return item;
      });
    });

  return state.map((item, i) => (
    <div key={i}>
      <TextField index={i} value={item.name} onChange={onChange} />
    </div>
  ));
};

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

@marrkeri 첫 번째 코드 조각에서 잘못된 것이 보이지 않습니다. dev 도구에서 강조 표시된 구성 요소는 컨텍스트를 사용하는 Field 이며 메모 구성 요소이며 areEqual 기능을 구현하는 TextField 가 아닙니다.

코드샌드박스 예제의 성능 문제는 컨텍스트를 사용하는 1000개의 구성 요소에서 비롯된 것이라고 생각합니다. 컨텍스트를 사용하는 하나의 구성 요소(예 Fields 리팩터링하고 해당 구성 요소(맵 포함)에서 각 값에 대해 TextField 를 반환합니다.

@marrkeri 첫 번째 코드 조각에서 잘못된 것이 보이지 않습니다. dev 도구에서 강조 표시된 구성 요소는 컨텍스트를 사용하는 Field 이며 메모 구성 요소이며 areEqual 기능을 구현하는 TextField 가 아닙니다.

코드샌드박스 예제의 성능 문제는 컨텍스트를 사용하는 1000개의 구성 요소에서 비롯된 것이라고 생각합니다. 컨텍스트를 사용하는 하나의 구성 요소(예 Fields 리팩터링하고 해당 구성 요소(맵 포함)에서 각 값에 대해 TextField 를 반환합니다.

당신이 말했듯이 나는 같은 생각 아래에 있었다 매번 다시 렌더링해야 하지만 ( ) 값이 변경된 경우에만. 하지만 주변에 패딩을 추가했기 때문에 아마도 개발 도구 문제일 것입니다. 그리고 그 대신 다시 렌더링됩니다. 이 사진을 확인하세요

하나의 구성 요소로 리팩토링하는 것에 대한 두 번째 요점을 파악하지 못했습니다. . 스냅샷 pls를 할 수 있습니까? 그리고 여러분은 최대 표시 수에 대해 어떻게 생각하십니까? 지연없이 괜찮은 것은 무엇입니까? 1000은 많은가요?

@marrkeri 저는 https://codesandbox.io/s/little-night-p985y 와 같은 것을 제안했습니다

이것이 react-redux가 안정적인 컨텍스트 API의 이점을 사용 하지 않고 Hooks로 마이그레이션할 때 컨텍스트에 현재 상태를 전달하는 것을

그래서 있는 것 같다.

옵션 4: 레거시 컨텍스트 시대와 마찬가지로 구독 기능을 컨텍스트 값으로 전달

사용법을 제어하지 않고(옵션 2-3에 필요) 가능한 모든 선택기를 열거할 수 없지만(옵션 1에 필요) Hooks API를 노출하려는 경우 유일한 옵션일 수 있습니다.

const MyContext = createContext()
export const Provider = ({children}) => (
  <MyContext.provider value={{subscribe: listener => ..., getValue: () => ...}}>
    {children}
  </MyContext.provider>
)

export const useSelector = (selector, equalityFunction = (a, b) => a === b) => {
  const {subscribe, getValue} = useContext(MyContext)
  const [value, setValue] = useState(getValue())
  useEffect(() => subscribe(state => {
      const newValue = selector(state)
      if (!equalityFunction(newValue, value) {
        setValue(newValue)
      }
  }), [selector, equalityFunction])
}

@Hypnosphi : 우리는 컨텍스트(v6 구현)에서 스토어 상태 전달을 중단하고 직접 스토어 구독(v7 구현)으로 다시 전환했습니다. 성능 문제와 컨텍스트로 인한 업데이트를 구제할 수 없기 때문입니다. v6 접근 방식을 기반으로 React-Redux 후크 API를 생성하는 것은 불가능합니다).

자세한 내용은 내 포스트 React-Redux의 역사 및 구현을 참조하십시오.

스레드를 읽었지만 여전히 궁금한 점이 있습니다. 위에 나열된 "옵션 1 2 3 4" 컨텍스트 변경 시 조건부로 다시 렌더링할 수 있는 유일한 옵션이 오늘 있습니까? 공식적으로 이 문제를 해결하기 위해 다른 작업이 진행 중이거나 "4가지 솔루션"이 충분히 수용 가능한 것으로 간주됩니까?

나는 다른 스레드에 썼지만 만일을 위해. 다음은 _비공식적인_ 해결 방법입니다.
userland의 useContextSelector 제안 및 use-context-selector 라이브러리.

솔직히 이것은 프레임워크가 우리가 권장하는 것처럼 기능과 후크에 완전히 들어갈 준비가 되지 않았다고 생각하게 만듭니다. 클래스와 라이프사이클 메서드를 사용하면 이러한 것들을 깔끔하게 제어할 수 있었고 이제 후크를 사용하면 훨씬 더 읽기 어려운 구문이 됩니다.

옵션 3이 작동하지 않는 것 같습니다. 내가 잘못하고 있습니까? https://stackblitz.com/edit/react-w8gr8z

@Martin , 나는 그것에 동의하지 않습니다.

후크 패턴은 잘 구성된 문서와 코드로 읽을 수 있습니다.
구조 및 React 클래스 및 수명 주기는 모두 기능으로 대체 가능합니다.
동등한 것.

불행히도 반응 패턴은 다음을 통해 React로 달성할 수 없습니다.
React 클래스 또는 후크.

2020년 1월 11일 토요일 오전 9시 44분 Martin Genev [email protected]
썼다:

솔직히 이것은 프레임워크가 아직 준비되지 않았다고 생각하게 만듭니다.
우리가 권장하는 것처럼 완전히 기능과 후크에. 수업과 함께
이러한 것들을 깔끔하게 제어할 수 있는 라이프사이클 방법이 있었습니다.
이제 후크를 사용하면 훨씬 더 읽기 어려운 구문이 됩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/facebook/react/issues/15156?email_source=notifications&email_token=AAI4DWUJ7WUXMHAR6F2KVXTQ5D25TA5CNFSM4G7UEEO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAI4DWUCO7ORHV5OSDCE35TQ5D25TANCNFSM4G7UEEOQ
.

@mgenev 옵션 3은 자식의 재렌더링을 방지합니다( <ExpensiveTree /> , 이름 자체가 말함)

@Hypnosphi 감사합니다, 맞습니다.
https://stackblitz.com/edit/react-ycfyye

다시 작성했고 이제 실제 렌더링(디스플레이) 구성 요소가 다시 렌더링되지 않지만 모든 컨테이너(연결된 컨텍스트)는 사용 중인지 여부에 관계없이 컨텍스트에서 prop이 변경될 때 렌더링됩니다. 이제 내가 볼 수 있는 유일한 옵션은 컨텍스트 분할을 시작하는 것입니다. 그러나 일부 항목은 진정으로 전역적이며 최고 수준에서 래핑되며 그 안의 소품을 변경하면 전체 앱에서 모든 컨테이너가 실행됩니다. 그것이 어떻게 성능에 좋을 수 있는지 이해하지 마십시오 ...

성능적으로 이것을 수행하는 방법에 대한 좋은 예가 어디에 있습니까? 공식 문서는 정말 제한적입니다

기본적으로 react-redux가 내부적으로 수행하는 옵션 4를 시도해 볼 수 있습니다.
https://github.com/facebook/react/issues/15156#issuecomment -546703046

subscribe 기능을 구현하려면 Observables 또는 EventEmitter와 같은 것을 사용하거나 기본 구독 로직을 직접 작성할 수 있습니다.

function StateProvider({children}) {
  const [state, dispatch] = useReducer(reducer, initialState)
  const listeners = useRef([])
  const subscribe = listener => {
    listeners.current.push(listener)
  }
  useEffect(() => {
    listeners.current.forEach(listener => listener(state)
  }, [state])

  return (
    <DispatchContext.Provider value={dispatch}>
      <SubscribeContext.Provider value={{subscribe, getValue: () => state}}>
          {children}      
      </SubscribeContext.Provider>
    </DispatchContext.Provider>
  );
}

관심이 있는 사람들을 위해 이 주제와 다소 관련이 있는 다양한 라이브러리를 비교합니다.
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode

나의 최근 노력은 다가오는 동시 모드에서 중요할 useTransition 로 상태 분기 지원을 확인하는 것입니다.
기본적으로 React 상태와 컨텍스트를 정상적으로 사용하면 OK입니다. (그렇지 않으면 this 와

감사합니다 @dai-shi 귀하의 패키지가 정말 마음에 들고 채택하려고 합니다.

@dai-shi 안녕하세요, 방금 react-tracked 라이브러리를 찾았고 약속대로 컨텍스트의 성능 문제를 해결하면 정말 좋아 보입니다. 여전히 실제적이거나 다른 것을 사용하는 것이 더 낫습니까? 여기에 use-reducer-async https://github.com/dai-shi/react-tracked/blob/master/examples/12_async/src/store로 미들웨어 수준을 만드는 방법도 보여줍니다. useReducer 사용하여 비슷한 작업을 수행했으며 비동기 미들웨어용으로 dispatch 를 내 것으로 래핑하고 Context 했지만 컨텍스트 래핑으로 인해 향후 렌더링 성능 문제에 대해 걱정하고 있습니다.

@bobrosoft react-tracked 는 꽤 안정적입니다(확실한 하나의 개발자 제품으로). 피드백은 매우 환영하며 그렇게 하면 라이브러리가 개선될 것입니다. 현재 내부적으로는 문서화되지 않은 React의 기능을 사용하고 있으며 앞으로 더 나은 프리미티브로 대체할 수 있기를 바랍니다. use-reducer-async 는 거의 잘못되지 않는 간단한 구문 설탕과 같습니다.

이 HoC는 나를 위해 일했습니다.
````
'반응'에서 React, { useMemo, ReactElement, FC } 가져오기;
'lodash/reduce'에서 수입 감소;

유형 선택기 = (컨텍스트: 모든) => 모든;

인터페이스 선택기 개체 {
}

const withContext = (
구성 요소: FC,
컨텍스트: 모든,
선택기: SelectorObject,
): FC => {
return (props: any): ReactElement => {
const 소비자 = ({ 컨텍스트 }: 모든): ReactElement => {
const contextProps = 축소(
선택기,
(acc: any, selector: Selector, key: string): any => {
const 값 = 선택기(컨텍스트);
acc[키] = 값;
반환 acc;
},
{},
);
사용메모 반환(
(): ReactElement => ,
[...Object.values(props), ...Object.values(contextProps)],
);
};
반품 (

{(context: any): ReactElement => }

);
};
};

기본 내보내기 withContext;
````

사용 예:

export default withContext(Component, Context, { value: (context): any => context.inputs.foo.value, status: (context): any => context.inputs.foo.status, });

이것은 redux mapStateToProps와 동등한 컨텍스트로 볼 수 있습니다.

redux의 connect()와 거의 유사한 임시 항목을 만들었습니다.

const withContext = (
  context = createContext(),
  mapState,
  mapDispatchers
) => WrapperComponent => {
  function EnhancedComponent(props) {
    const targetContext = useContext(context);
    const { ...statePointers } = mapState(targetContext);
    const { ...dispatchPointers } = mapDispatchers(targetContext);
    return useMemo(
      () => (
        <WrapperComponent {...props} {...statePointers} {...dispatchPointers} />
      ),
      [
        ...Object.values(statePointers),
        ...Object.values(props),
        ...Object.values(dispatchPointers)
      ]
    );
  }
  return EnhancedComponent;
};

구현 :

const mapActions = state => {
  return {};
};

const mapState = state => {
  return {
    theme: (state && state.theme) || ""
  };
};
export default connectContext(ThemeContext, mapState, mapActions)(Button);

업데이트: 궁극적으로 동적 리스너(마우스 이동 시)를 사용하여 빠르게 변화하는 세분화된 데이터를 위해 EventEmitter로 전환했습니다. 나는 그것이 작업을 위한 더 나은 도구라는 것을 깨달았습니다. 컨텍스트는 일반적으로 데이터를 공유하는 데 적합하지만 새로 고침 빈도가 높지는 않습니다.

컨텍스트를 선언적으로 구독하거나 구독하지 않는 것이 아닌가요? useContext()를 사용하는 다른 구성 요소에서 구성 요소를 조건부로 래핑합니다.

주요 요구 사항은 내부 구성 요소가 상태를 가질 수 없다는 것입니다. 분기 때문에 효과적으로 다른 인스턴스가 될 것이기 때문입니다. 또는 구성 요소를 미리 렌더링한 다음 cloneElement를 사용하여 소품을 업데이트할 수 있습니다.

일부 구성 요소는 렌더링의 컨텍스트와 관련이 없지만 "값을 읽어야" 합니다. 내가 무엇을 놓치고 있습니까?

Context._currentValue 는 프로덕션에서 사용하기에 안전합니까?

가능한 한 저렴하게 렌더링할 수 있는 컨텍스트에 구성 요소를 구독하려고 합니다. 하지만 그런 다음 나는 옛날 방식으로 스파게티 코드로 소품을 전달하거나 업데이트에 논리적인 것이 없을 때 업데이트 구독을 피하기 위해 메모를 사용하는 것을 발견했습니다. 메모 솔루션은 구성 요소 렌더링이 컨텍스트에 따라 달라지지만 그렇지 않은 경우 ...

@vamshi9666 많이

https://recoiljs.org/ 이 문제에 대한 좋은 해결책을 찾았습니다. React에 통합하면 굉장할 것 같아요.

@vamshi9666 많이

한 곳에서만 사용했으며 초기 목표는 jsx에서 상태 관리를 분리하지만 상용구를 만들지 않는 것입니다. 그래서 돌연변이 기능을 확장했을 때 redux의 감속기 및 액션 생성기 패턴과 매우 유사해 보였습니다. 어느 것이 더 좋습니다. 그러나 나는 그것이 실제로 이미 거기에 있을 때 무언가를 재발명할 요점을 보지 못합니다.