반응 언어 환경에 대한 몇 가지 사고

오늘 나는 상하문 API에 대해 토론할 것이다. 이것은 가장 중요한 개념 중의 하나이며, React를 사용할 때 알아야 할 API이다.자, 우리 시작합시다.
본 블로그에서 저는'React 상하문을 어떻게 설정하고, React 상하문을 어떻게 사용하는지'를 상세하게 소개하지 않지만, 제 생각만 공유하고 싶습니다.

1. 컨텍스트 API가 필요한 이유는 무엇입니까?

만약 당신이 React를 사용하고 있다면, 도구 드릴링이라는 아주 짜증나는 일을 처리해야 할 수도 있습니다.이런 상황에서 당신은 일부 구성 요소를 통해 도구를 전달해야 한다. 그러나 이 구성 요소들은 진정으로 도구를 필요로 하지 않는다. 단지 아이(또는 한 아이)가 이 도구를 필요로 하기 때문이다.
기본적으로 Context API는 일부 도구와 여러 구성 요소와 공유할 수 있는 데이터를 저장할 수 있는 글로벌 스토리지를 만들 수 있는 기회를 제공합니다.

2. Redux와 비교

등등, 이것이 Redux(또는 그 어떠한 주 관리 라이브러리)가 해결하고자 하는 문제입니까? 만약 그것이 내장된 React라면, 왜 우리는 이런 주 관리 라이브러리가 필요합니까?
물론 도구 연습을 처리하기 위해서라면 이 라이브러리들은 지금처럼 인기가 없을 것이다.
나는 Redux를 사용한 경험(아직 약간의 시간적 반충)이 있기 때문에 나는 Redux와 상하문 API를 비교하는 데 중점을 둘 뿐이다.

a. 특징

상하문이 생기면 하나의 저장소만 남는다. 여러 구성 요소에 사용할 수 있도록 전역 변수를 놓을 수 있다.

그러나 Redux에 대해서는 상황이 다르다. 이것은 전 세계 상점을 제공할 뿐만 아니라 응용 프로그램을 통해 당신의 상태를 추적하는 등 다른 기능을 제공한다. (Redux 확장을 통해 매우 강력하고 필수적인 확장이다. 만약에 Redux를 사용한다면 디버깅 과정이 훨씬 수월할 것이다)

또 하나 언급할 만한 것은 논리와 동작을 구성 요소에서 분리하는 데 도움을 준다는 것이다(실제로 내가 보기에 그것은 더 이상'첨가'가 아니다)

사용 상태 기록

등 중간부품

또한 "Context Hell"이라는 컨텍스트 API의 단점을 해결합니다(앞으로 몇 분 동안 심도 있게 논의할 예정입니다).

에는 더 많은 내용이 있다. 왜냐하면'생태계'(내가 그것을 이렇게 불러도 될지 모르겠다)가 매우 크고 많은 라이브러리가 있다. 예를 들어 Redux thunk, Redux saga, Redux persist 등이다.그것들은 React 응용 프로그램이 많은 문제를 처리하는 방식을 바꾸었다. (물론, 내게는 응용 프로그램이 점점 커질 것이다.)

b. 설정

상하문 API는 하나의 (주요) 용법만 있기 때문에 설정 과정은 매우 간단하다. 상하문, 상하문 제공 프로그램과 상하문 사용자를 초기화하는 세 가지가 필요하다.컨텍스트 API는 React의 내장 기능이므로 다른 LIB를 설치할 필요가 없습니다.

레드ux를 사용할 때 제가 레드ux를 사용하지 않는 가장 큰 이유 중 하나는 설정 과정에 관한 것입니다. 해야 할 일이 많습니다. 매번 새로운 동작이 있을 때마다너는 많은 파일을 추가해야 한다. (물론 모든 파일을 한 파일에 넣을 수 있다. 이것은 매우 좋지만, 현실 프로젝트에서 응용 프로그램이 확장성을 가지도록 하기 위해서, 예를 들어 app.actions.js, app.reducer.js, app.selector.js 등 여러 파일로 나누는 것을 권장한다)그러나 이것은 목적이 아니다. 만약 다른 서버와 상호작용을 하고 Redux를 충분히 이용하려면 Redux thunk나 Redux saga를 설치해야 한다. 이로써 당신이 작성해야 할 논리와 코드 줄 수가 점점 커진다.이것은 나에게 악몽이다.

3. 열세

가게

내가 기능 부분에서 언급한 바와 같이 상하문 API의 단점 중 하나는 소비자가 공급자 하나만 사용할 수 있다는 것이다. 즉, 서로 다른'저장'(상하문)의 데이터를 사용하려면 이렇게 그것들을 함께 포장해야 한다.

<ThemeContext.Provider value={theme}>
   <UserContext.Provider value={signedInUser}>
          <Layout />
       </UserContext.Provider>
</ThemeContext.Provider>

그런데 여기 뭐가 안 좋아요?

우선, 디버깅은 비교적 어렵다. 왜냐하면 당신은'글로벌 상점'이 많기 때문이다.이는 Redux의 한 원칙인'단일 진실의 출처'와 대비된다.네가 가진 상점이 많을수록 더욱 조심해야 한다.

그 다음으로 여기서 언급할 만한 또 다른 것은 성능에 관한 것이다. 만약에 외부 상하문의 어떤 값이 변화하면 포장된 모든 구성 요소에 대한 재렌더링을 촉발할 수 있다. 상기 예시된 양파와 같은 상하문을 포장할 수 있다.물론 대부분의 경우, 이것은 우리가 기대하는 응용 프로그램의 행위이지만, 일부 경우, 변경 값에 무관심한 내부 구성 요소를 다시 보여주는 것은 무의미하고 성능 문제를 초래할 수 있다.

b. 기능 제한

앞서 기능 부분에서 언급한 바와 같이 React Context는 전역 저장소에 불과하기 때문에 React Context는 보통 소형 프로젝트에 사용된다.더 큰 프로젝트가 관련되었을 때, Redux (또는 다른 상태 관리 libs) 는 풍부한 기능을 가지고 있기 때문에 선택이다.물론, 우리는 여전히 React 상하문과 다른 상태 관리 라이브러리를 사용할 수 있다.그러나 내가 보기에, 우리가 이미 '글로벌 상점' 을 개설한 이상, 왜 또 하나를 개설해야 하는가.맞습니까?

4. 마지막 생각

비록 기능이 제한되어 있지만, 나는 여전히 React Context를 좋아한다.특히 다른 LIB가 데이터를 전역 상태로 저장할 수 있을 때(예를 들어 Apollo Graphql,React query 등)맞춤형 연결의 탄생.
오늘은 여기까지.다음에 봐요.안녕히 계십시오.