Redux: Egghead의 Redux 스크린캐스트 시리즈

:+1:

1. 로컬 구성 요소의 상태 대 전역 상태
2. 여러 리듀서에 의해 처리되는 액션 대 1:1 액션 리듀서 관계
3. 첫 번째 작업이 완료된 직후 두 번째 작업이 트리거되어야 하는 경우 작업 체인(특히 비동기 작업 체인) 처리.
4. 불필요한 재재생을 방지하기 위한 최적화 기술(일괄 처리, 재선택 등).

:+1:

시리즈의 처음 16개 에피소드를 방금 보았고 내가 일하는 회사에서 내부 교육에 사용할 수 있는 훌륭한 리소스라고 생각합니다. 그러나 상태 트리에 대해 일반 객체와 deep-freeze 만 사용하고 immutable-js 와 같은

이에 대한 귀하의 생각을 아는 것이 좋습니다.

믹스에 Immutable을 던지면 Redux와 Immutable API를 구별하는 법을 배워야 하거나 Immutable이 필요하다고 가정하는 등 초보자를 혼란스럽게 할 수 있습니다. 하지만 몇 가지 고급 레슨을 위한 좋은 아이디어입니다!

믹스에 Immutable을 던지면 Redux와 Immutable API를 구별하는 법을 배워야 하거나 Immutable이 필요하다고 가정하는 등 초보자를 혼란스럽게 할 수 있습니다. 하지만 몇 가지 고급 레슨을 위한 좋은 아이디어입니다!

알겠습니다. 이 결정에 대한 귀하의 생각을 아는 것이 좋습니다 :-).

@smashercosmo가 말한 것:+1:

단위 테스트. TDD.

@catland가 말한 것:+1:

이러한 방식으로 광범위한 문서와 간결한 튜토리얼을 통해 우수한 js 라이브러리를 생성할 수 있는 당신의 기술에 깊은 인상을 받았습니다.

모든 비디오를 본 후 우편으로 보낼 특정 비디오에 대한 많은 피드백을 받았습니다. 그러나 결론은 이것이 Redux에 대한 소개 그 이상이라는 것입니다. 코드 사례 및 구성 요소 아키텍처 등을 다룹니다. 정말 대단하고 매우 교육적입니다. 그래도 동영상은 세 그룹으로 나눌 수 있다고 생각합니다. Redux basic, redux 비하인드 스토리, redux with react.

향후 비디오에서는 특정 개념에 대한 반응을 줄이고 비동기 작업 및 테스트에 대해 더 많이 보고 싶습니다.

놀랍도록 잘했습니다. 계속하십시오! :)

비디오 21에서 TodoApp 구성 요소는 더 이상 클래스일 필요가 없으며 함수일 수 있습니다. 어떻게 이러한 깨달음을 얻었는지 설명할 수 있다면 좋을 것입니다. 왜 이것이 기능적 구성 요소에 적합한 후보이며 이것이 어떤 이점을 제공합니까?

이거 정말 좋다.

@smashercosmo 목록의 항목 3도 알고 싶습니다.

@wpannell이 말한 것! 단위 테스트/TDD!

고급 문서에서 다루는 주제에 대한 비디오도 보고 싶습니다.

단위 테스트와 관련하여 구체적으로 무엇에 관심이 있습니까?
5, 11, 12과에서는 감속기를 단위 테스트하는 방법에 대한 아이디어를 제공합니다.

...그건 좋은 질문이야. 모카 테스트를 하면 과정이 많이 달라지나요?

설마. 그러나 나는 그것이 일련의 고급 수업을 위한 좋은 주제라고 생각합니다. 단위 테스팅 리듀서, 액션 생성기, 컴포넌트 등

첫째, 훌륭한 비디오. 이미 redux를 이해했지만 상쾌했습니다.
더 고급 비디오를 만드는 경우 비동기 작업/미들웨어를 제안할 수 있습니다.
단위 테스트에 실제로 적용 범위가 필요하다고 생각하지 마십시오. 감속기 기능을 호출하고 이에 대해 주장할 수 있습니까?

예, 모카 테스트에서 expect 래핑하는 것 외에는 별 다른 것이 없는 것 같습니다. :엄지손가락:

고맙게도 모든 것이 너무 간단합니다!

개체 ID 해시의 불변성(예: [post._id]: {...post} ).

API 엔터티 배열을 가져와서 ID 해시를 생성하기 위해 reduce 함수에 너무 많이 의존하고 있습니다. normalizr 이 이 중 일부를 처리할 것이라는 것을 알고 있지만 A 지점에서 B 지점으로 안내하는 EggheadIO 비디오와 유사한 비디오를 원합니다. 이는 Redux 기반에만 있는 것이 아니라 얽혀 있습니다.

@raquelxmoss

비디오 21에서 TodoApp 구성 요소는 더 이상 클래스일 필요가 없으며 함수일 수 있습니다. 어떻게 이러한 깨달음을 얻었는지 설명할 수 있다면 좋을 것입니다. 왜 이것이 기능적 구성 요소에 적합한 후보이며 이것이 어떤 이점을 제공합니까?

그것은 실제로 내 쪽에서 약간의 조잡한 수업 계획이었습니다. 나는 그것을 처음부터 기능적 구성 요소로 만들 수 있다는 것을 너무 늦게까지 깨닫지 못했습니다. 클래스보다 함수를 사용하는 이점은 단순하므로 가능하면 언제든지 이 작업을 수행하십시오. 기본적으로 componentDidMount 또는 상태와 같은 수명 주기 후크가 필요하지 않은 경우 기능 구성 요소를 사용합니다.

도움이 되도록 이러한 코드 조각을 실제 디렉토리 구조로 분할하는 방법에 대한 교훈을 찾을 수 있습니다. 모든 것이 있는 한 아마 작동할 것이지만 폴더 이름 지정 규칙(구성 요소/컨테이너/저장소/리듀서 등), 어떤 종류의 파일이 어떤 폴더에 들어가는지 등에 대한 권장 규칙이 있다는 것을 알고 있습니다.

또한 고급 감속기 구성을 원합니다.

복잡한 구성 요소 재사용(리듀서 또는 여러 리듀서, 일련의 작업, 작업 생성자, 일부 서버 측 API에 액세스, redux 형식과 같은 여러 React 구성 요소로 구성되지만 더 실제 앱에 고유함). 여기에는 모듈식 디렉토리 구조 구성도 포함됩니다.

전체를 보았다, 아주 좋아! ES6/7 구문( Object.assign -like), React 0.14 함수 구성 요소의 사용 및 불변의 것을 피하는 것에 감사했습니다.

권장되는 코드 아키텍처를 설명하는 비디오일 수 있습니다.

그리고 ES6/7 구문을 사용하도록 문서를 업데이트하시겠습니까? (그 방향으로 PR을 환영합니까?)

단위 테스트, API 미들웨어 생성, Redux로 OAuth/일부 유형의 사용자 인증 수행, redux에서 Immutable 사용(설정 방법, 모범 사례 등)

이 시리즈는 단일 원자 상태인 Redux 및 관련 철학에 대한 훌륭한 소개 역할을 합니다. 나는 당신이 인지 과부하를 유발하는 것을 피하면서 핵심 원칙에 귀를 기울이는 일을 잘했다고 생각했습니다. 작업한 환경도 쉽게 복제할 수 있으므로 실습 부분에 더욱 쉽게 접근할 수 있습니다.

@gaearon 예시 영상에서 액션을 처음부터 표준적인 { type: string, payload: Object } 로 구성하는 것에 대해 어떻게 생각하시나요? 페이로드가 작업 개체 자체에 배치되는 카운터 목록 예제에 대해 이야기하고 있습니다. { type: string, index: number } . 이것은 나에게 안티 패턴처럼 보입니다.

예제 비디오의 작업을 처음부터 표준 { type: string, payload: Object }으로 구성하는 것에 대해 어떻게 생각하십니까? 페이로드가 작업 개체 자체에 배치되는 카운터 목록 예제에 대해 이야기하고 있습니다. { 유형: 문자열, 색인: 숫자 }. 이것은 나에게 안티 패턴처럼 보입니다.

어떤 식으로든 안티 패턴이 아닙니다. 일반적인 액션 오브젝트입니다. FSA 는 괜찮지만 _컨벤션_입니다. Redux 자체의 어떤 것도 이 규칙의 이점에 의존하지 않으므로 우리는 그것을 시행하고 싶지 않습니다.

사람들은 원래 Flux 문서에서 payload , source 에 대해 온갖 마법 같은 것을 생각하곤 했습니다. 그것들이 존재하는 이유를 이해하지 못하고 그것들이 필요한지 여부를 신중하게 평가하지 않고 맹목적으로 복사했습니다. 나중에 그들은 Flux가 복잡하고 장황하다고 불평했지만 실제로 많은 경우 장황한(필수는 아닌) 부분 자체를 복사했습니다.

이 수업에서는 Redux의 필수 부분만 가르칩니다. 내가 상수를 소개하지 않는 방법에 주목하세요. 사람들이 상수에 너무 많이 집중하고 중요하지 않다는 사실을 놓치기 때문입니다. 처음부터 튜토리얼 비디오에 넣는 것보다 문자열에 몇 가지 오타를 만든 후에 상수의 이점을 이해할 가능성이 더 큽니다. FSA와 같은 다른 컨벤션도 마찬가지라고 생각합니다. 편리하다고 생각되면 꼭 사용하세요. 하지만 수업에서 요구하지 않는 경우에는 설교하지 않겠습니다.

@gaearon 좋습니다 . 단순한 비정형 접근 방식에 익숙해진 사람들이 규칙을 적용하지 않음으로써 더 큰 앱을 관리할 수 없게 만들지 않기를 바랍니다.

@sompylasar

나는 예제가 비디오 튜토리얼보다 규칙을 더 잘 보여준다고 생각합니다. 예는 "여기에 이러한 원칙을 중심으로 일부 코드를 구성하는 방법이 있습니다"라는 독단적인 영역이 있으며 비디오는 이러한 원칙 자체에 대한 것입니다. 이것이 다른 예에서 다른 규칙을 볼 수 있는 이유이며 프로젝트를 시작하기 전에 대부분의 사람들은 다른 방법을 맛보기 위해 다른 예를 살펴봅니다.

또한 FSA를 따르지 않는 것에 대해 구조화되지 않은 것은 전혀 없습니다. { type: 'STUFF', id: 1 } 는 본질적으로 { type: 'STUFF', payload: { id: 1 } } 보다 나쁘지 않습니다. 그것은 취향과 (때로는) 도구 규칙의 문제일 뿐입니다. 작업 개체를 payload 적게 유지한다고 해서 작업하기가 더 어려워지는 것은 아닙니다.

곧 에그헤드에 대한 몇 가지 redux 단위 테스트 강의가 나올 예정입니다 😄

Dan이 첫 번째 크랙을 할 수 있도록 한동안 Redux 수업을 보류했습니다. 기다릴만한 가치가 있습니다.

"Idiomatic Redux로 애플리케이션 빌드"는 훌륭한 고급 과정이 될 것입니다 👍

@joelhooks 둘 다 놀랍습니다!

jsbin을 사용하는 대신 webpack과 핫 리로딩을 사용하여 프로젝트를 설정하는 것을 보고 싶습니다. 이것을 현실 세계로 가져 가라. 나는 그것이 redux에만 국한되지 않는다는 것을 알고 있지만 그것이 잘 맞을 것이라고 생각하고 당신이 이것을 가르칠 적임자입니다 :)

@kevinrenskers이 비디오 시리즈 아니지만, 당신이 뭔가를 해부 같은 느낌 경우 가 있습니다 몇 가지 참조 할 수있는 정말 좋은 예 boilerplates가!

Dan의 예제와 Webpack 구성에 대한 프로젝트 구조를 요청하신 분들입니다.

https://github.com/urbanvikingr/todo를 확인

나는 비디오에서 Dan의 코드와 일치하도록 Redux를 React 문서로 업데이트하기로 약속했습니다. 그것은 다음 2주 안에 완료될 것입니다 - 나의 Holiday 프로젝트 :) - 계속 지켜봐 주십시오.

Egghead.io 비디오에 대한 나의 위시리스트:
Jasmine을 사용한 액션/리듀서 테스트
미들웨어에 대한 심층 분석(thunk/promise)

스크린캐스트는 Redux에 대한 매우 유용한 소개입니다. 내가 듣고 싶은 것은 라우팅 및 서버 측 렌더링을 수행하는 Redux 방식입니다.

@grigio 라우팅에 대한 https://github.com/rackt/redux/issues/1145 토론에 관심이 있을 수 있습니다.

@urbanvikingr 감사합니다, 구독했습니다. 투표가 종료된 것 같지만 #1168에 투표했을 것입니다.

수업은 실제로 꽤 좋은데 "가게"라고 하면 "하찮은 일"처럼 들린다는 점이 주의를 산만하게 합니다.

여기 있는 모든 사람들은 그것을 눈치채고 주의를 분산시켰습니다. 그들은 그것을 제기하기에는 너무 정치적으로 옳습니다. 그래서 예, 나는 _그_ 사람이 되기로 결정했습니다. 다른 사람이 하지 않을 경우를 대비해 :)

나는 결국 영어를 더 잘하게 될 것이다. 현재로서는 이것이 내가 할 수 있는 최선입니다 ;-)

@gaearon Redux에 대한 설명을 정말 잘 하셨습니다. 귀하와 귀하의 오픈 소스 성과에 경의를 표합니다.

놀라운 수업 세트. 특히 "소스 읽기" 방식으로 처음부터 각 핵심 Redux 기능을 다시 구현하는 방식이 마음에 들었습니다. 튜토리얼과 모든 문서가 Redux에 대해 얼마나 명확한지 감동한 다른 사람을 두 번째로 소개합니다. 지금까지 2년 간의 프론트엔드 발전을 따라잡는 사람으로서 개념은 내 마음을 감싸기가 어려웠지만 문서는 그렇게 하는 데 놀라울 정도로 도움이 되었습니다. 계속 해 주세요. 감사합니다!

(또한 @jugimaster의 말을 듣지 마십시오. 모든 사람이 당신의 억양에 주의를 산만하게 하고 "너무 정치적으로 올바르

@ianstormtailor
그건 그렇고, 그것은 악센트가 아닙니다 :)

나도 "신경쓰지" 않았지만, 확실히 주의가 산만해졌습니다!

하지만 한편으로는 6개 국어를 공부한 사람으로서 항상 언어를 올바르게 말하는 것을 _해왔습니다_. 그런 점에서 누군가가 내 실수를 지적해줘서 개인적으로 고맙게 생각합니다.

안녕하세요 @gaearon 님

당신의 코스를 절대적으로 좋아했습니다. 잘 했어! 매우 도움이 되었습니다.

최근 Egghead 과정에 세 가지 Redux 테스트 비디오 수업을 추가했습니다.
https://egghead.io/series/react-testing-cookbook

내 희망은 그들이 당신이 한 모든 놀라운 일에 대해 칭찬을 해주기를 바랍니다!

확실한 코스!

Redux 지식뿐만 아니라 현대적 관행 지식을 전반적으로 향상시킵니다! 계속 좋은 일만 하세요 :+1: :tada:

이봐, 방금 비디오에 코드에 대한 링크/참조가 없다는 것을 깨달았습니다. 어쩌면 명백하고 아마도 충분히 간단한 사용자는 비디오를 복사할 수 있습니다. 하지만 많은 사람들이 동영상의 정확한 코드가 있는 저장소를 통해 이점을 얻을 수 있다고 생각합니다. 왜 안 될까요?

모든 강의에 대한 코드 스니펫은 Egghead 구독자에게 제공됩니다. :-)
비디오는 무료지만 플랫폼은 돈을 벌어야 더 많은 코스에 투자하고, 강사에게 장비를 보내고, 비디오를 호스팅하고, 웹 사이트를 개선하는 등의 작업을 수행할 수 있습니다.

즉, 코스와 거의 일치하는 examples/todos 폴더가 있습니다.

... 좋아, 그럼 내가 놓친거야? 링크를 찾는 중...

@gaearon이 사과하고 방금 비디오를 다시 방문했습니다. 코드는 바로 거기에 있습니다 :)... 동영상을 보고, 멤버십을 구매하고, 다른 사람을 보고... 실제로 로그인한 redux 동영상으로 돌아갔습니다. 건배.

그런데 일부 사람들은 성적표가 정확하지 않다고 불평했습니다.
수정을 위해 PR을 보내주십시오: https://github.com/eggheadio/egghead-redux-transcripts

@gaearon redux를 사용하기로 결정하고 egghead에서 redux vids를 찾았습니다. 비디오는 내가 redux를 배우기 시작하는 데 정말 도움이 되었습니다. 앞으로 더 많은 실제 사례를 보는 것이 좋을 것입니다.

따라서 앞으로 redux 비디오 교육에 대한 제 제안은 고급 구성, 리팩토링에 대한 심층 분석 및 확실히 reselect를 사용하는 방법입니다. 언제 리팩토링해야 하는지에 대한 직관이 있는 것 같습니다. 따라서 함수형 프로그래밍은 redux와 매우 밀접하게 연결되어 있으므로 리팩토링 시기와 한 가지 일을 잘하는 함수를 식별하는 방법에 대한 몇 가지 팁을 얻는 것이 정말 유용할 것입니다.

내가 만들고 있는 앱에는 여러 개의 대규모 데이터 컬렉션이 있으며 테이블에 넣고 데이터 정렬 및 페이지 매김과 같은 작업을 수행해야 합니다. 선택기를 사용할 때와 만들기 작업을 사용할 때를 결정하는 데 어려움이 있습니다. 사용자가 테이블에서 일부 상태를 "상속" 저장하도록 하기 때문에 현재 USERS_SORT_TABLE 작업과 SORT_TABLE 작업이 있습니다. 사용자 저장소별로 정렬되는 할일 저장소에 대한 SORT_TABLE 작업을 원하지 않았기 때문에 이 작업을 수행했습니다.

내 솔루션이 DRY가 아니라는 것을 알고 있지만 올바르게 수행하는 방법을 모르겠습니다. 현재로서는 테이블을 채우고자 하는 모든 상점에 대해 "SOMETHING"_SORT_TABLE 작업을 생성해야 합니다. 이는 잘못된 것으로 알고 있지만 올바른 방법을 모르겠습니다. 또 다른 부작용은 액션에 이름을 접두사로 붙여 다른 저장소를 분리해야 하기 때문에 내 액션 이름이 거대해지고 있다는 것입니다. 이것은 옳을 수 없습니다.

다음은 몇 가지 예제 코드입니다.

/* actions.js */
// ...
export const USER_MOVE_COLUMN = 'USER_MOVE_COLUMN'

export function userMoveColumn (columnIndex, moveToIndex) {
  return {
    type: USER_MOVE_COLUMN,
    columnIndex,
    moveToIndex
  }
}

export const DATA_TABLE_MOVE_COLUMN = 'DATA_TABLE_MOVE_COLUMN'
// ...

/* reducers.js */
// ...
export default function user (state=userInitialState, action) {
  switch (action.type) {
    // ...
    case USER_MOVE_COLUMN:
      return dataTable(state, assign(
        action,
        {type: DATA_TABLE_MOVE_COLUMN}
      ))
    // ...
    default:
      return state
  }
}
// ...
export default function dataTable (
  state=dataTableInitialState,
  action,
  key='dataTable')
{
  switch (action.type) {
    // ...
    case DATA_TABLE_MOVE_COLUMN:
      return {
        ...state,
        [key]: {
          ...state[key],
          columns: move(
            state[key].columns, action.columnIndex, action.moveToIndex
          )
        }
      }
    // ...
    default:
      return state
  }
}

따라서 테이블과 "모델" 저장소 사이에 존재해서는 안 되는 종속성을 생성했음을 알 수 있습니다(모델 저장소는 개체 배열에 대해 컬렉션 키를 사용해야 함). 그리고 dataTable은 "부모" 리듀서의 상태를 조작하는데, 그렇게 해서는 안 됩니다. 거기에서 선택기를 사용해야 한다는 생각이 들었지만 이 글을 작성할 당시에는 UI에 표시되는 내용을 변경하기 위해 큰 저장소를 복제하는 것을 피하려고 했습니다.

그래서 현재 저는 이러한 문제 중 일부를 해결하기 위한 재선택과 다른 문제를 해결하기 위한 리팩토링 기술을 배우기 위해 고군분투하고 있습니다. 첫 번째 Redux 과정은 나를 위험하게 만들기에 충분했습니다. 이제 제대로 하는 방법을 배우고 싶습니다. :)

너무 장황하지 않고 도움이 되었기를 바랍니다. 명확하고 정직한 피드백을 제공하려고 노력합니다.

저를 도와줄 수 있는 모든 종류의 영혼을 위해 저는 이미 다른 Dan의 댓글에서 /examples/real-world/reducers 를 찾았으며 현재 위에서 설명한 문제 중 일부를 재작업하고 있습니다. 내가 해결책을 찾았을 때 도움을 주느라 시간을 낭비하지 않았으면 합니다.

경고 감사합니다 :)

내 프로젝트에 redux-devtools를 통합하는 것은 저에게 큰 고통이었습니다. 나는 거기에 무엇이 있고 어떻게/언제 사용하는지 설명하는 에그헤드 시리즈를 높이 평가했을 것입니다. 나는 당신이 언제 무엇을 사용해야하는지 설명하는 PR을 읽었지만 .. 너무 많은 것들이 너무 많아서 혼란스러워했습니다. hmr, transform 3, redux hot reloader는 react hot reloader 등등..

위에서 설명한 몇 가지 문제로 어려움을 겪고 있는 다른 사람을 위해 Redux의 모든 상용구는 물론 네임스페이스 작업을 대부분 제거할 수 있는 프로젝트를 만들었습니다. 여기를 참조

@granteagon 이 커플은 리듀서에서 액션 크리에이터로

액션/리듀서 생성 위에 래퍼 또는 추상화를 생성하는 대부분의 사람들은 항상 직접적으로 함께 결합될 것이라고 가정하는 경향이 있습니다. 분명히, 내 앱에서 지금까지 내 작업의 _대부분의_에는 정확히 하나의 처리 논리 덩어리가 있지만 트리의 여러 부분을 업데이트해야 하는 곳이 몇 군데 있었습니다.

@gaearon @markerikson 액션 크리에이터에 리듀서를 연결합니다. 그러나 시간의 90%는 괜찮거나 심지어 원하는 것입니다. 나머지 10%는 여전히 손으로 코딩한 접근 방식을 사용할 수 있습니다. 말씀해주신 부분은 생각해보고 향후 발전을 위해 고려하겠습니다.

@granteagon @gaearon

reduxr과 유사한 로컬 추상화를 사용했기 때문에 여기에 추가된 결합이 없다고 주장합니다. 액션과 리듀서 간에 1:1 매핑을 강제하는 것은 없습니다. 동일한 작업을 수신하는 두 개의 다른 슬라이스에 두 개의 리듀서를 가질 수 있습니다.

const counterReducersA = {
  // this counter increments by 1 each time
  increment: (state, action) => state + 1
}

const counterReducersB = {
  // this counter increments by 2 each time
  increment: (state, action) => state + 2
}

const counterA = reduxr(counterReducersA, 0);
const counterB = reduxr(counterReducersB, 0);

const rootReducer = combineReducers({
  counterA: counterA.reducer,
  counterB: counterB.reducer
});

store.dispatch(counterA.action.increment());  // increments both counters

물론, 같은 이름의 "리듀서" 기능이 두 개 이상 있는 경우(즉, 동일한 작업에 응답), 암시적으로 둘 다 작업 페이로드가 특정 모양을 "예상"해야 합니다. 이는 완전히 유사합니다. 바닐라 redux에 두 개의 감속기가 모두 동일한 type 상수를 처리하도록 하려면 --- 둘 다 동일한 동작 모양을 기대해야 합니다.

@gaearon 커플링이 무슨 말인지 제가 잘못 이해

썽크 구현을 보여주기 전에 미들웨어가 없는 비동기 흐름을 보여주는 것이 도움이 될 수 있다고 생각합니다.

다소 관련이 있지만 문서가 미친 듯이 도움이 되는 동안 비동기 흐름 페이지의 이 설명은 돌이켜 생각해보면 정말 저를 혼란스럽게 만들었습니다. "미들웨어가 없으면 Redux 저장소는 동기 데이터 흐름만 지원합니다."

@battaile : 그게 사실이기 때문입니다 :) 미들웨어가 없으면 비동기 store.dispatch 를 호출할 때마다 작업은 감속기 기능으로 바로 이동하고 Go를 전달하지 않고 $200를 수집하지 않으며 AJAX 호출을 위해 도중에 중지하지 않습니다.

스토어 인핸서는 dispatch 와 같은 기능을 자신의 버전으로 마무리할 수 있으므로 applyMiddleware 는 실제 상점의 dispatch 기능에 도달하기 전에 "미들웨어 파이프라인"의 추상화를 제공합니다. . 이는 기본적으로 표준 Redux 흐름 _내부에서_ 원하는 비동기 작업을 수행할 수 있는 허점을 제공합니다.

따라서 미들웨어 없이도 여전히 완전히 비동기 작업을 수행할 수 있습니다. 모든 것이 실제로 Redux와 관련된 것과 완전히 별개로 발생해야 합니다.

그것이 사실이기 때문입니다 :)

나는 그것이 거짓이라고 말하지 않았다, 나는 그것이 나를 궤도에서 벗어났다고 말했다 :)

나는 단지 다음과 같은 일을 하고 싶었습니다.

const mapDispatchToProps = (dispatch) => ({
  onclick(searchTerm) {
    dispatch(actions.requestOrders(searchTerm));

    return fetch('http://localhost:49984/Order/Search?search=' + searchTerm)
      .then(response => response.json()).then(response => {
        dispatch(actions.receiveOrders(searchTerm, response));
      })
      .catch((err) => {
        dispatch(actions.receiveOrdersError('An error occurred during search: ' + err.message));
      });
  },
});

나는 이것이 쉽게 추악해질 수 있다는 것을 알고 있지만 개념적으로는 보는 것이 유용하다고 생각합니다. 아니면 적어도 내 경우에는 그랬다.

"미들웨어 없이 Redux 스토어는 동기식 데이터 흐름만 지원한다"는 데 동의합니다. 오해의 소지가 있습니다.

기술적으로 "내부"와 "외부"를 구분하고 싶다면 그 말이 사실일 수 있지만 비동기를 수행하는 유일한 방법은 미들웨어를 추가하는 것이라고 사람들이 믿게 하는 경우, 아마도 우리는 이를 다시 말하거나 자세히 설명할 수 있습니다. 그것.

예, 차이점은 비동기 동작이 기술적으로 dispatch "내부"보다는 구성 요소 수준에서 더 많이 발생한다는 것입니다. 사소한 차이지만 유효한 것입니다.

나는 그 진술이 기술적으로 옳지 않다고 주장하는 사람은 없다고 생각합니다.

@markerikson 내부와 외부의 구분이 중요한 구체적인 예가 있는지 궁금합니다.

한 가지 예는 비동기 미들웨어가 디스패치된 썽크(또는 약속 등)를 볼 수 있기 _before_ 체인의 미들웨어를 원하는 경우일 수 있습니다. 그 미들웨어가 _무엇을_ 할 것인지 _무엇을__ 확신할 수 없지만, 그런 것을 원하는 것이 실현 가능하다고 생각합니다.

음... 구체적으로 "구체적인" 예에 대해서는 확실하지 않습니다. 전반적으로 "outside"와 "insie"의 구분은 dispatch 를 처음으로 호출하기 _전_ 또는 _후_에 발생하는지의 문제입니다. "outside" 및 "before"인 경우 모든 비동기성과 논리가 React, Angular 또는 다른 무엇이든 관계없이 뷰 레이어에 더 많이 연결됩니다. "내부" 및 "이후"인 경우 비동기성과 논리는 저장소 수준에 있으며 보기 계층에 연결되지 _않습니다_.

이것은 실제로 오늘 일찍 Reddit 토론에서 만들려고 했던 요점입니다: https://www.reddit.com/r/reactjs/comments/4spbip/has_anyone_inserted_a_controllerpresenter_layer/ .

"어떤 작업을 발송하고 언제 발송합니까?"에 대한 질문입니다. 나머지 절반은 "이러한 작업에 대한 응답으로 내 상태를 어떻게 업데이트합니까?"인 비즈니스 논리의 핵심 부분입니다. 액션 관리가 썽크(thunks)와 무용담(sagas) 등에 있는 경우 해당 코드가 React 구성 요소, Angular 컨트롤러, jQuery 클릭 핸들러, Vue 구성 요소 인스턴스 또는 다른 것에 의해 시작되었는지 여부는 실제로 중요하지 않습니다. 핵심 로직은 UI 레이어 외부에 있으며 UI 레이어는 실제로 필요한 데이터를 스토어 밖으로 가져와 표시하고 사용자 입력을 앱 로직 함수 호출로 바꾸는 역할을 합니다.

그런 의미에서 "내부" 대 "외부"의 질문이 중요하다고 말하고 싶습니다. 왜냐하면 논리가 앱 수준에 있는지 UI 수준에 있는지를 개념적으로 구분하기 때문입니다.

@markerikson 이 질문에 대해 함께

참고: 편의를 위해 thunk 를 사용하여 실제로 redux-thunk이든 redux-promise이든 간에 비동기에 대한 임의의 미들웨어 접근 방식을 나타냅니다.

UI 레이어는 사용자 상호 작용을 핸들러에 연결합니다. 누군가 버튼을 클릭하면 UI가 _some_ 핸들러를 호출하도록 조작됩니다. 종종 구성 요소는 이러한 핸들러를 props로 수신합니다. 예를 들어 바인딩된 작업 생성자일 수 있습니다. UI는 핸들러를 호출할 때 어떤 일이 발생하는지 알지 못합니다. --- 그냥 호출합니다.

"핸들러"가 (미들웨어에 의해 처리될) 함수를 디스패치하는지 또는 비동기 호출을 실행하고 _then_이 일반 작업을 디스패치하는지 여부는 UI 레이어에 차이가 없습니다. --- UI는 완전히 불가지론적입니다. _가능_ 불가지론적일 수 있음)

썽크를 사용하는지 여부에 관계없이 "앱"의 많은 부분이 이러한 "처리기"에 있습니다. 일반적인 react/redux 앱에서 이러한 "핸들러"는 종종 일종의 액션 생성자입니다. 모든 비동기 항목을 썽크로 작성하고 발송할 수 있습니다. 또는 모든 비동기 항목을 dispatch 인수로 허용하는 함수로 작성할 수 있습니다. 구성 요소의 관점에서 볼 때 someHandler(dispatch) OR dispatch(someHandler()) 또는 상위에서 상속된 바인딩된 작업 작성자의 경우 두 경우 모두 someHandler() 입니다. UI 레이어와 이 차이를 완전히 가리는 bindActionCreators 버전을 빌드할 수 있습니다.

redux-thunk를 사용하여 액션 제작자로 작성된 react/redux 애플리케이션을 제공하면 UI 계층을 _근본적으로_ 변경하지 않고도 redux-thunk를 완전히 교체하고 비 미들웨어 접근 방식을 사용할 수 있습니다. (참고: getState 을 주입하는 위치/방법에 대해 설명하고 있지만 여기에서는 사소한 세부 사항이라고 _믿습니다_).

따라서 '내부'와 '외부'의 구분이 '앱 수준' 또는 'UI 수준'이라는 사실을 받아들이는 데 문제가 있습니다.

토론에 감사드리며 부정적인 의견이 나오지 않기를 바랍니다.

이 코스는 훌륭합니다. 사람들이 코스에 대한 커뮤니티 노트 리포지토리로 의견을 보낼 수 있도록 이것을 닫습니다: https://github.com/tayiorbeii/egghead.io_redux_course_notes

그리고 댄이 뭉친 다음 시리즈도 꼭 확인해보세요! https://egghead.io/courses/building-react-applications-with-idiomatic-redux