환경 대응 지침💫

반응 언어 환경🤔?
React 컨텍스트는 props을 각 레벨로 수동으로 전달할 필요 없이 어셈블리 트리를 통해 데이터를 전달하는 방법을 제공합니다.React에서 데이터는 일반적으로 모 어셈블리에서 해당 서브어셈블리로 속성으로 전달됩니다.

Context is like a global object to the React component sub-tree 🌐.

언어 환경이 어떤 문제를 해결했는가😟?
React 응용 프로그램의

에서 부모 구성 요소가 서브 구성 요소에 데이터를 장시간 전달할 수 있지만, 이 데이터가 부모 구성 요소의 직접 서브 구성 요소가 아닌 여러 층의 서브 구성 요소에서 사용될 때 문제가 발생할 수 있습니다.

다음 그림을 보도록 하겠습니다.📈.
Component A은 분명히 직접 서브어셈블리 B, C의 주요 서브어셈블리입니다. 이러한 서브어셈블리는 component A에서 매개변수를 수신하여 서브어셈블리에 전달할 수 있지만 Component E은 Component A의 데이터를 필요로 하고 Component B은 이 데이터를 필요로 하지 않으면 Component B에 데이터를 전달하는 것이 불필요해집니다.

Props drilling, a term to describe when you pass props down multiple levels to a nested component, through components that don't need it.

이것이 바로 React context의 장점입니다. 아주 멋진 방식을 제공합니다.😎 React 애플리케이션의 각 서브어셈블리에서 언제든지 데이터를 사용할 수 있습니다.

우리는 어떻게 언어 환경을 사용합니까😕?
React 상하문은 props을 사용하지 않고 React 응용 프로그램의 모든 구성 요소에서 데이터를 전달하고 사용할 수 있도록 합니다.
새로운 React Context API 사용은 four 주요 단계에 따라 다릅니다.
🔸 createContext 방법을 사용하여 상하문을 만듭니다.그리고 이 함수는 공급자와 사용자를 포함하는 대상을 되돌려줍니다.

import React from 'react';

const AuthContext = React.createContext();

🔸 그런 다음 Provider 어셈블리를 사용하여 모/주 어셈블리를 둘러쌉니다.
🔸 공급자 구성 요소에서 하위 구성 요소를 포장하고 value이라는 도구를 받아들인다.이 value은 무엇이든 가능합니다!

<AuthContext.Provider value={value}>
  <Demo />
</AuthContext.Provider>

🔸 구성 요소 트리의 공급자 아래에 있는 사용자 구성 요소를 사용하여 상태의 하위 집합을 가져옵니다.

function Demo() {
  return (
    <AuthContext.Consumer>
      {value => <h1>{value}</h1>}
    </AuthContext.Consumer>
  );
}

📌 전체 예를 살펴보겠습니다.

import React from 'react';

export const AuthContext = React.createContext();

export default function App() {
 return (
   <AuthContext.Provider value="Happy">
    <Demo />
   </AuthContext.Provider>
 )
}

function Demo() {
  return (
    <AuthContext.Consumer>
      {value => <h1>{value}</h1>} /* prints happy */
    </AuthContext.Consumer>
  );
}

응용 프로그램 구성 요소 위에서 React.createContext()으로 상하문을 만들고 그 결과를 변수 AuthContext에 넣고 있습니다.

은 거의 모든 상황에서 구성 요소가 다른 파일에 있기 때문에 우리가 여기에서 한 것처럼 내보내기를 원합니다.

Note that we can pass an initial value to our value prop when we call React.createContext().

이 만든 상하문은 두 가지 속성을 가진 대상이다. Provider과 Consumer이다. 이 두 속성은 모두 구성 요소이다.

Things to keep note down what Provider actually do ✍️:

➡️ It holds one single javascript value that can be anything: an array, a function or an object.

➡️ It won’t cause its children to re-render: The context’s provider’s direct children won’t re-render every time the provider renders, but the consumers will.
This rule is only valid for re-renders caused by the provider internally (state), but if his parent re-renders (props), the provider’s children will re-render as well.

➡️ All subscribers will re-render when the context value changes.

은 AuthContext를 사용하는 어플리케이션 구성 요소입니다.특히 AuthContext.Provider은 저희 value을 응용 프로그램의 모든 구성 요소에 전달하기 위해 저희 공급자 구성 요소를 주변에 포장했습니다. 이 예는 Demo입니다.

은 AuthContext.Provider에 전체 구성 요소 트리에 전달할 값을 넣습니다.이를 위해 value 아이템으로 설치했습니다.여기, 즐거움.

은 Demo에서 또는 우리가 상하문에서 제공한 내용을 사용하고자 하는 어느 곳에서든지 소비자 구성 요소를 사용합니다. AuthContext.Consumer은 전달하는 값을 사용하고 이른바 렌더링 도구 모델을 사용합니다.
이것은 단지 소비자 구성 요소가 prop으로 우리에게 제공한 함수일 뿐이다.이 함수에 대한 보답으로 우리는 value을 되돌려 사용할 수 있다.

useContext 갈고리를 사용하면 위아래 문장의 다른 방식을 사용합니다.
📌 다음은 useContext 사용과 같은 예입니다.

import React from 'react';

export const AuthContext = React.createContext();

export default function App() {
 return (
   <AuthContext.Provider value="Happy">
    <Demo />
   </AuthContext.Provider>
 )
}

function Demo() {
 const value = React.useContext(AuthContext);
 return <h1>{value}</h1>; 
}

useContext accepts the context type as parameter and returns the context value of the nearest provider of that type. If there is no such provider, then the default context value will be returned.

애플리케이션의 성능에 영향을 미칩니까?💥?
🔹 간단히 말하면, 만약 공급자가 많은 다른 값을 조합한 값을 가지고 있다면, 응용 프로그램의 성능이 대폭 떨어지고, 같은 공급자의 많은 소비자들이 다시 나타날 것이다.
🔹 공급자의 포장기가 내부 원인(상태일 수 있음)으로 인해 다시 나타날 때 그 하위 항목은 다시 나타나지 않고 사용자만 나타날 수 있다.이것은 당신의 공급업체가 가치를 공급업체에서 소비자로 전달하는 것과 같아서, 양자 간의 모든 것을 직접 소홀히 하는 것과 같다.
🔹 따라서 여러 개의 상하문과 공급자를 가지는 것은 충분히 가능하다.

Redux와 context API는 어떻게 다릅니까?
보시다시피 관련된 개념은 Redux와 크게 다르지 않습니다.
그럼 위아래 문장이 레드ux를 대체한 건가요?
답안은 부정적이다🙅.
Redux는 도구(전송 도구)를 전달하는 방식일 뿐만 아니라 지속성을 허용하고 중간부품을 지원하며 더욱 많은 장점을 가진다.
나의 건의는 레드ux를 사용하여 복잡한 전 세계 상태 관리를 하고 기둥이 우물을 파는 환경을 고려하는 것이다.
본고는redux에 대해 토론할 계획이 없기 때문에, 이 비교에 관한 더 많은 정보를 읽을 수 있도록 유용한 자원을 삭제할 것입니다👇.

회복 StackOverflow.

단의 게시물은 약 You Might Not Need Redux이다.

본고에서 우리는 도구를 전달하여 구성 요소 간에 데이터를 공유하는 것이 아니라 React 상하문을 어떻게 쉽게 사용하는지 연구하였다🚢.
사용자의 용례에 따라 간단한 도구,React Context, 심지어Redux와 같은 제3자 라이브러리를 사용하여 구성 요소 간에 데이터를 공유하는 것을 더 좋아할 수 있습니다.

아디아샤 M⚡

🔊 '반응 어경'에 대해서 얘기를 해볼게요.🔊🔸React context는 "도구"를 사용하지 않고 React 프로그램에서 필요한 모든 구성 요소의 데이터를 전달하고 사용할 수 있도록 합니다.🔸다시 말하면, 이것은 전 세계에서 국가를 관리하는 방식의 하나이다🌐.이거 재밌잖아요.😯?
2022년 1월 18일 오후 18:48
계속 인코딩😉. 읽어주셔서 감사합니다.💖.
원하는 대로 연결하십시오.)