Redux: 토론 요청: Redux "보일러플레이트", 학습 곡선, 추상화 및 독창성

몇 가지 아이디어:

• redux, react-redux, redux-thunk가 이미 함께 연결된 공식 redux-preset 패키지
• dispatch(actionType, payload) 는 액션 크리에이터의 필요성을 줄일 수 있습니다.
• 내장된 jumpstate 스타일 감속기 생성기, 예: createReducer({[actionType]: (state, payload) => state}, initState)

redux를 많이 사용하는 내가 아는 대부분의 사람들은 확장성이 좋지 않다는 것을 알게 되어 redux-thunk에서 멀어지고 결국 너무 많은 일을 시작하는 액션 제작자로 이어지며 오히려 측면 관리를 위해 다른 것을 사용하게 됩니다. - redux-observable 또는 redux-saga와 같은 효과.

특히 redux를 시작할 때 그 매력을 이해할 수 있지만 '모범 사례 상용구 패키지'의 일부로 번들링하는 것이 가장 좋은 아이디어인지 확신할 수 없습니다.

따라서 이 부분은 나에게 더 중요합니다(이것은 문제를 해결하기 위한 아이디어가 아니라 적어도 나에게 중요한 제약 조건이 될 것입니다).

Redux는 "가장 간결한 방법"이 아니라 데이터 흐름을 명확하고 읽기 쉽게 만들기 위한 것입니다.

Redux의 좋은 점은 그것이 프레임워크라기보다 디자인 패턴에 가깝고 당신이 보는 모든 코드(스토어와 react-redux 제외)가 당신의 것이라는 점입니다.

Jumpstate를 살펴보면(지금까지는 이에 대해 몰랐습니다) Redux에 대해 내가 본 첫 번째 추상화 계층 중 좋아 보이는 것입니다. 심지어 좋아! 그러나 동시에 MobX와 같은 다른 프레임워크에서 벗어나게 하고 동일한 것을 테이블에 가져오는 여러 프레임워크를 갖는 것은 그다지 유용하지 않습니다. 따라서 Redux가 다른 도구와 동일한 환경에 있기 때문에 진공 상태에서 Redux를 개선할 수 있는 방법뿐만 아니라 Redux가 나머지 부분과 다른 점에 초점을 맞추는 것이 중요합니다.

또 다른 중요한 사실은 신규 사용자가 Redux를 사용할 때 겪는 많은 문제가 Redux 자체가 아니라 JavaScript라는 것입니다. Angular와 같은 다른 큰 프레임워크는 JavaScript 자체를 추상화합니다. Redux 감속기를 작성하는 것은 단순히 초보자에게 익숙하지 않을 수 있는 바닐라 자바스크립트 "디자인 패턴"을 적용하는 것이며 사람들이 대신 블랙박스를 사용하고 싶게 만들 것입니다.

마지막으로 많은 상용구 감소 라이브러리는 구성 요소, 감속기 및 작업 생성자 사이에 1:1:1 관계를 추가하려고 시도합니다(3개 모두가 아닐 수도 있지만 종종 2개). , 여러 리듀서의 상태를 사용하는 여러 구성 요소 등. 그것은 직장과 다른 장소에서 내가 대답하는 #1 질문 중 하나이며 매우 유용합니다. 따라서 해당 영역에서 도움이 되는 도구는 이것을 잃지 않아야 합니다(또한 "스위치가 이상하다"는 세계 최고의 주장이 아닙니다).

따라서 IMO, CTA에는 좋은 바닐라 JavaScript 리소스를 연결하고 "시작하기" 개념에 따라 "이유"를 더 많이 문서화하고 작업을 단순하게 유지하는 것이 포함됩니다. 많은 새로운 개념을 전혀 배우지 않고도 Redux에서 거대한 애플리케이션을 구축할 수 있습니다. 저는 redux를 관찰할 수 있는 사람이지만 문제 없이 Thunk를 사용하는 수십만 줄의 코드 앱을 보았습니다(작은 앱이 썽크로 인해 사고를 치는 것도 보았습니다). 아주 적은 수의 "핵심" 개념을 소개하고 그것들이 어떻게 수많은 개념에 적용될 수 있는지 보여주는 것은 많은 도움이 됩니다.

"비용에 관계없이 모든 상용구는 줄여야 합니다"는 오늘날 소프트웨어 엔지니어링 커뮤니티 전체의 문제입니다. 해결하기가 더 어렵습니다.

처음부터 redux를 사용하여 내 주요 관심사는 코드를 읽거나 쓸 때 N개의 파일 사이를 이동해야 했으며 단일 UI 부분의 b/c 로직이 코드베이스 전체에 걸쳐 작업, 작업 유형 및 여러 감속기. UI의 모든 위치에서 상태 트리의 어느 부분에나 접근할 수 있고 단일 작업(내가 redux를 사용하는 주요 이유)에 대한 응답으로 상태의 다른 부분을 변경할 수 있다는 점이 정말 마음에 듭니다. 단일 행동에 대한 응답으로 상태가 변경될수록 내 논리가 더 흐려집니다. 나는 사용자가 이것 또는 저것을 했을 때 일어난 일을 단순히 읽거나 쓸 수 없습니다. 그러나 내가 원하는 것은 다음과 같이 설명할 수 있습니다.

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

결국 나는 redux-interactions + redux-tree 를 생각해 냈고 지금까지는 꽤 만족합니다.

현재 프로젝트의 접근 방식:

참고, 응용 프로그램 요구 사항에 따라 매우 다를 수 있습니다. :) 실시간 개체 업데이트를 추가하면 아마도 sagas 또는 observable이 thunk/promise보다 이점을 제공할 것입니다.

• redux-thunk
• 약속 미들웨어
• 클라이언트 페더 앱 주위의 래퍼인 "api 래퍼", 페이로드가 API 호출에 대한 약속인 액션 생성자 service(name, method, ...opts) (예: 미들웨어가 이를 선택하고 x_FULFILLED , x_PENDING 및 x_REJECTED ). 이 작업의 이름을 덮어쓸 수도 있습니다.

먼저 componentDidMount() 를 사용하여 API를 호출하고 데이터를 구성 요소 상태에 저장합니다. 그러나 이를 위해 API 래퍼를 사용합니다. 즉, 작업이 계속 전송되고(요청 정보인 메타를 포함하여 로거 미들웨어에 의해 기록됨) 해당 구성 요소에 대한 저장소를 사용하도록 리팩토링하려는 경우 필요한 모든 것입니다. to는 작업을 수신하는 감속기를 추가하는 것입니다. 로컬 상태만 사용하여 시작하고 해당 구성 요소의 상태를 다른 구성 요소에서 액세스/수정해야 할 때 redux로 리팩터링합니다. 즉, 모든 것에 대한 종이 흔적을 제공하기 때문에 모든 곳에서 redux를 사용하는 매력을 봅니다. 현재 팀과 지원 일정을 감안할 때 atm에 도움이 되지 않습니다.

redux-saga를 조금 사용해 보았지만 가장 복잡한 비동기 흐름은 로그인/로그아웃이므로 작동하므로(코드가 크게 복잡하지 않음) 전환할 큰 이유는 없습니다(하지만 테스트할 가치가 있을 수 있음). 이유 - iterable + mock은 테스트하기에 좋은 방법입니다). redux-observable 예를 들어 이벤트를 멋지게 두 번 클릭하려는 경우와 같이 관찰 가능 항목이 자체적으로 이점을 제공하지 않는 한 즉각적인 이점을 볼 수 없습니다.

우리는 리듀서를 반환하는 자체 팩토리 함수를 갖고 사용자 정의 기능 위에 자체 고차 리듀서를 갖춤으로써 상용구에서 약간 벗어났습니다. 항목을 수정하는 작업).

내가 해야 한다고 생각하는 것은 기본 반응 앱에서 작업하는 거대한 튜토리얼이며, 구성 요소 간 통신과 관련된 문제를 시연한 다음, redux를 도입하고, 계속 진행 하여 특정 상황에서 발생하는 문제를 시연하고 어떻게 할 수 있는지 보여줍니다. redux-x로 도움을 받으세요 . 즉, 언제, 무엇을 사용해야 하는지에 대한 안내입니다. 이 방향에 대한 토론이 있는 블로그 게시물이 분명히 있습니다.

또한 관련성이 있는 것은 gothinkster/react-redux-realworld-example-app 에서 사용되는 패턴에 대해 요약입니다.

redux를 많이 사용하는 내가 아는 대부분의 사람들은 확장이 잘 되지 않는다는 것을 알게 되어 결국 redux-thunk에서 멀어지게 됩니다.

나는 당신이 말하는 것을 이해하지만 여기에 내 이면적인 우려가 있습니다. 우리는 거대한 JS 개발자 그룹이 아직 _화살표 기능_ 및 기타 기본 ES(6|2015) 기능을 사용하지 않는다는 일화적인 증거를 점점 더 많이 보고 있습니다. , 이해 부족, 협박 등으로 인해. Redux를 시작하고 싶어하는 사람들과 Redux가 소개하는 _patterns_ 학습으로 혜택을 볼 수 있는 사람들이 먼저 Observable이나 Generator를 배우기를 기대하는 것은 아마도 너무 많은 것을 요구한다고 생각합니까?

Redux-thunk는 또한 일반적으로 redux 미들웨어가 두뇌를 구부린다는 점에서 약간 복잡하지만 최소한 JS를 작성하는 경우 선택하기 쉬운 함수/콜백일 뿐입니다. "best-practice-always-redux"가 아닌 "learn-redux"로 표시되더라도 단일 다운로드를 통해 사용할 수 있는 시작하기 위한 관련 도구의 완전한 패키지를 갖는 아이디어가 정말 마음에 듭니다. create-react-app이 설정한 모든 것을 배울 때 조정이 필요한 것과 유사하게, 이것은 자신의 조정을 장려할 수 있고, 아마도 간단한 redux-thunk 설정을 saga 등을 자체 형식으로 사용하도록 변환하는 방법을 보여줄 수 있습니다. "탈출"의 ...

그냥 몇 가지 생각.

나는 당신이 말하는 것을 이해하지만 여기에 내 이면적인 우려가 있습니다. 우리는 거대한 JS 개발자 그룹이 아직 화살표 기능 및 기타 기본 ES(6|2015) 기능조차 사용하지 않는다는 일화적인 증거를 점점 더 많이 보고 있습니다. , 이해 부족, 협박 등으로 인해. Redux를 시작하고 싶어하고 Redux가 도입한 패턴을 학습하여 혜택을 받을 수 있는 사람들이 Observable이나 Generator를 먼저 배우기를 기대하는 것은 아마도 너무 많은 것을 요구한다고 생각합니까?

빙고! 우리는 많은 사람들이 JS를 처음 접하는 환경에 있습니다. 특히 그 사람들이 다른 생태계(자바, 레일 등)의 숙련된 소프트웨어 엔지니어라면 모르는 개념을 배우기 전에 알고 있는 개념을 빠르게 시도하고 적용할 것이고 제대로 작동하지 않고 막히게 될 것입니다. 기능적인 UX 디자인 패턴에 뛰어들기 전에 사람들이 JS를 깊이 이해하도록 설득하는 가장 좋은 방법은 무엇인지 모르겠습니다.

Redux 문서에는 지금 무언가를 찾고 있고 Redux 위에 전체 라이브러리를 채택하고 싶지 않은 독자를 위해 Reducing Boilerplate에 대한 섹션이 있습니다.

우리는 이 논의에 대해 약간 주의를 기울여야 하며 이것이 아마도 이미 많이 자전거를 탈 수 있다는 것을 깨달아야 합니다. Redux 팀은 여기에서 제안될 수 있는 많은 것들을 듣고, 고려하고, 거부했습니다. 우리가 이미 논의된 것들에 대해서만 싸우면 이 토론에서 아무 것도 나오지 않을 가능성이 큽니다.

즉, 모든 사람(신규 및 경험자)이 프레임워크에 더 쉽게 액세스할 수 있도록 하는 방법에 대해 이야기하는 것이 좋습니다.

상용구를 줄이기 위해 제안하는 모든 것은 필요할 때마다 추상화 아래의 항목으로 돌아갈 수 있어야 합니다. 추상화 작성자가 생각하지 못한 한 가지 추가 사항이 필요했기 때문에 나중에 하위 수준으로 돌아가기 위해 추상화를 채택하는 것은 재미가 없습니다.

Redux 학습 곡선은 가파르지만 일단 개념을 이해하면
추상화 계층은 종종 사라집니다.

이 경우 Redux의 어떤 부분을 개선하기 위해 제안하고 있는지 궁금합니다. 즉시 다시 추가할 필요가 없는 부분을 제거하거나 추상화하시겠습니까?

이것은 약 1년 전 직장에서 강연을 위해 만든 전체 반응/리덕스 수명 주기의 다이어그램입니다.

여기에는 꽤 많은 부분이 있지만, 그 중 어느 것도 없이 Redux가 잘 작동한다고 상상할 수 없습니다. 컨테이너는 때때로 성가신 일이지만 컨테이너를 제거하면 뷰 로직과 데이터 레이아웃이 긴밀하게 연결됩니다. 작업을 제거하면 기본적으로 Redux를 처음부터 사용하는 요점을 놓치는 MVC가 됩니다. 해당 다이어그램의 "보기"는 저장소를 구독하고 반응 구성 요소를 렌더링하는 기능으로 모델링할 수 있기 때문에 이미 거의 존재하지 않습니다.

전체 프레임워크 자체에서 제거해야 할 상용구가 많지 않다고 생각합니다. 아마도 액션 생성자, 리듀서 또는 컨테이너와 같은 프레임워크의 개별 부분에 있는 상용구를 참조하고 있을 것입니다. 이 경우 위에서 언급한 상용구 줄이기 페이지의 팁은 이미 이러한 문제의 대부분을 해결합니다. 우리는 그것을 "더 나은"것으로 만들기 위해 그 위에 아무것도 필요하지 않습니다. (참고: 더 나은 것을 만들기 위해 무언가를 추가하는 데 개방적이지 않다는 것은 아닙니다. 단지 아직 보지 못했을 뿐입니다.)

아마도 이것은 상용구 감소 문제가 아니라 Redux 교육을 개선하는 문제일 것입니다. 프레임워크가 초보자에게 어렵다면 Redux 문서를 개선하고 더 쉽게 접근할 수 있도록 해야 할 수 있습니다. 아마도 감소하는 상용구 팁 중 일부는 문서에서 더 적극적으로 광고해야 할 수도 있습니다.

필요한 단계(보일러 플레이트)의 양을 줄이는 것이 항상 문제를 해결하는 것은 아닙니다. 내 게시물의 맨 처음부터 내 요점을 강조하기 위해 사람들이 사용해야 할 모든 방법을 생각하지 않았기 때문에 폐기될 추상화를 작성하고 싶지는 않습니다.

지금까지 좋은 토론. 제가 볼 수 있는 일반적인 "보일러 플레이트" 관련 불만 사항에 대한 몇 가지 간단한 예를 살펴보겠습니다.

• "객체를 즉시 반환하기 위해 '액션 생성기' 함수를 작성해야 하는 이유는 무엇입니까?"
• "간단한 새 기능을 추가하려면 너무 많은 파일을 터치해야 합니다! 또한 상수 및 함수 이름에 대해 동일한 이름을 계속 반복하고..."
• "AJAX 호출을 위해 이러한 '미들웨어'가 필요한 이유는 무엇입니까?"
• "왜 모든 것에 switch 문을 사용해야 합니까?"
• "이 dispatch 가 필요한 이유는 무엇입니까? 작동하려면 이 모든 기능을 마무리해야 하는 이유가 무엇입니까?"

그리고 이러한 유형의 주석에 대한 몇 가지 구체적인 예는 다음과 같습니다.

• Redux를 구현하는 것은 지루합니다.
• 최소한의 Redux 설정
• Jumpstate README 및 Jumpstate + Redux + CRA - 파견 또는 작업 생성자가 필요하지 않습니다!

그리고 이러한 "보일러플레이트" 문제에 대한 일부 응답을 즉시 삭제하려면 나열된 5가지 범주 중 " dispatch "만 실제로 _필수_됩니다. 나머지:

• 액션 생성자를 사용할 _가지는_ 없지만 일관성을 유지하는 좋은 방법입니다(내 게시물 Idiomatic Redux: Why use action creators? )
• 액션 생성자, 액션 상수, 리듀서에 대해 완전히 별도의 파일을 가질 필요는 없습니다. "ducks" 패턴 은 모든 것을 하나의 파일에 모으는 데 널리 사용되는 접근 방식입니다. 여러 리듀서가 하나의 작업을 수신하도록 하는 기능을 "숨기기"하는 단점이 있습니다. Redux는 궁극적으로 파일 구조가 무엇인지 신경 쓰지 않습니다.
• 컴포넌트에서처럼 Redux 외부에서 완전히 비동기 작업을 _할 수_ 있습니다. 그러나 Redux에서 비동기 흐름을 위한 미들웨어가 필요한 이유는 무엇입니까? 에서 Dan의 설명에 따라 , 일반적으로 구성 요소 외부에서 해당 논리를 추출하는 것이 좋으며 미들웨어는 Redux 저장소에 액세스하는 동안 비동기 작업을 수행하기 위한 "허점"을 제공합니다.
• 반드시 감속기에서 switch 문을 사용할 필요는 _없습니다_. 주어진 변수에 대해 여러 값을 처리하는 가장 "명백한" 방법일 뿐입니다. 조회 테이블, if/else 문 및 원하는 다른 모든 것이 좋습니다( FAQ에 따라: switch 문을 사용해야 합니까? )
• 유용한 일이 발생하려면 실제로 store.dispatch() 를 호출해야 _해야_ 합니다. 이것이 Redux의 기본 설계 결정입니다. 액션 생성자를 바인딩하면 연결되지 않은 자식 구성 요소에 전달할 수 있으며 함수가 호출될 때마다 여전히 디스패치되도록 할 수 있습니다.

따라서 전반적으로 이러한 "보일러플레이트" 문제에서 _필수_인 것은 거의 없습니다. 문서의 예제와 중복 제거 코드 및 관심사 분리와 같은 "좋은 프로그래밍 방법"의 조합입니다.

@markerikson 이 제기한 질문은 정말 공정하다고 생각하며 과거 어느 시점에 나 자신 적이 있습니다.

Redux는 어떤 의미에서는 데이터 모델링을 위한 "저수준" 라이브러리입니다. 그러한 저수준 라이브러리와 마찬가지로 대부분의 경우를 설명하기 위해 쉽게 추상화할 수 있는 많은 것을 노출합니다. @gaearon 이 원래 그렇게 하지 않은 이유는 라이브러리를 최대한 작고 유연하게 유지하기를 원했기 때문이라고 생각합니다. 그 결정 덕분에 우리는 Redux 코어에 모든 것을 가질 필요 없이 Redux 위에 다양한 것들을 구축할 수 있었습니다.

Redux 위에 좋은 라이브러리를 개발하고 안정화하는 올바른 경로(예: Jumpstate?)를 고려해야 합니다. 우리는 사람들에게 이를 가르치는 것으로 시작한 다음 필요할 때 Redux를 직접 사용할 수 있는 쉬운 경로를 제공합니다.

Redux는 핵심 코드베이스에서 훨씬 더 많은 것을 필요로 한다고 생각하지 않으며 영구적으로 추상화해야 하는 부분이 보이지 않습니다. (그렇다면 알려주세요 :smile:) 제 ​​생각에는 Redux 코어에서 무언가를 추가하거나 제거하여 얻을 수 있는 것이 많지 않습니다.

모든 사람이 사용할 수 있을 만큼 안정적이고 유연하게 라이브러리를 개선하는 것이 더 나은 옵션일 수 있습니다. 말했듯이 "보일러 플레이트"는 실제로 많이 필요하지 않으므로 Redux 자체를 수정하는 대신 Redux 상단의 라이브러리에서 제거합시다.

다른 커뮤니티에서 이런 일이 발생하는 예는 Rust 프로그래밍 언어입니다. "mio" 라는 Rust 프로그래밍 언어를 위한 비차단 IO 라이브러리가 있습니다. Redux와 마찬가지로 작고 낮은 수준에 중점을 둡니다. 문제는 정말 어렵고 상용구로 가득 차 있기 때문에 아무도 직접 사용하지 않는다는 것입니다. 대부분의 사람들은 mio를 기반으로 하고 매우 유용하고 인체공학적으로 만들어주는 tokio 라는 다른 라이브러리를 사용합니다. 이런 식으로 mio의 배관이 필요한 사람은 직접 사용할 수 있지만 빨리 만들고 싶은 사람은 tokio를 사용할 수 있습니다.

우리는 유사한 모델을 채택해야 합니다.

@sunjay 의 몇 가지 의견을 확장하려면 다음을 수행하십시오.

최근 #775에 내용을 잘 포착하는 댓글이 있었습니다.

Redux는 충분한 구조와 유연성의 균형을 제공하는 일반 프레임워크입니다. 따라서 개발자가 그래픽 디버거 또는 미들웨어와 같은 것을 재사용할 수 있는 동시에 사용 사례에 대한 맞춤형 상태 관리를 구축할 수 있는 플랫폼을 제공합니다.

예, Redux는 여러 면에서 "단지 패턴"입니다. 핵심 라이브러리는 기능이 완벽합니다. 실제 반쯤 계획된 변경 사항은 제안된 인핸서 구조 조정( #1702, #2214 ) 및 combineReducers 더 유연하게 만드는 것( #1768 , #1792 등)과 같은 것입니다. ).

Redux가 만들어진 지 거의 2년이 지났고 이제 사람들이 Redux를 어떻게 사용하고 있는지 잘 알 수 있습니다. 예를 들어, @jimbolla 는 #2214에서 알려진 모든 상점 강화 장치 목록을 수집하고 작동 방식과 용도를 분류했습니다. 저는 여전히 Redux의 단순성과 유연성에 대한 열렬한 팬이지만 Redux를 기반으로 일반 사용을 단순화하고 사람들의 문제를 해결할 수 있는 여전히 관용적인 추상화를 보고 싶습니다.

준 관련 주제의 또 다른 세트와 개인적으로 뚜렷한 관심이 있는 것은 "캡슐화된 논리/구성 요소"( @slorber 의 "Elm/Redux를 사용한 확장 가능한 프론트엔드" 플레이그라운드 기준) 및 "플러그"에 대한 아이디어입니다. -and-play Redux 설정"(https://github.com/brianneisler/duxtape/issues/1 , https://github.com/jcoreio/redux-features/issues/7 등의 실험에서 볼 수 있음). 전역 상태 및 앱 설정은 일부 사용 사례에 적합하지만 다른 사용 사례에는 적합하지 않습니다.

흥미로운 관련 사항으로 @toranb 는 https://github.com/ember-redux/ember-redux 에서 Redux용 Ember 래퍼를 만드는 훌륭한 작업을 수행했습니다. Ember 세계는 _정말__ "구성보다 관례"이므로 ember-redux 는 redux-thunk 등을 포함하여 합리적인 기본 저장소 구성을 설정합니다. 그러한 접근 방식이 도움이 될 수 있습니다.

네, 저는 여기에서 여러 가지 다양한 생각을 쏟아내고 있습니다. 하지만 그것들은 다양한 방식으로 관련되어 있습니다. 전반적으로 Redux를 배우고 사용하는 데 대한 장벽을 낮추고 전반적으로 고급 사용 사례를 활성화하고 싶습니다.

Redux는 전문화되지 않은 일반 API입니다. 이것은 더 많은 경우를 다루면서 더 장황하게 만듭니다. 그 힘은 복잡한 소프트웨어에 있는 반면, 새롭거나 단순한 프로젝트는 필요 범위를 벗어납니다.

그러나 일반 API를 기반으로 전문화를 구축할 수 있습니다. 예를 들어 일반적인 경우에 상용구를 줄이는 https://github.com/acdlite/redux-actions 를 사용합니다. 나는 여전히 redux의 모든 기능을 사용하고 있으며 그 인터페이스를 갖는 것만으로는 내 요구 사항에 충분하지 않습니다.

다른 문제는 엄청나게 복잡한 응용 프로그램의 고통을 경험하지 않은 새로운 사람들이 요점이 무엇인지 궁금해하는 것입니다. 글쎄, 그들에게 그들은 고통을 경험할 때까지 redux를 사용하지 않아야 할 것입니다. 그러나 Dan의 egghead 시리즈는 이 지점을 아주 쉽게 지나칠 수 있습니다.

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/building-react-applications-with-idiomatic-redux

참조: 추상화의 스펙트럼: https://www.youtube.com/watch?v=mVVNJKv9esE

언급한 바와 같이 redux-actions 는 일부 상용구를 제거하는 데 상당히 능숙합니다. .toString 를 첨부하여 방정식에서 상수를 제거하는 것은 정말 좋은 아이디어입니다. 그러나 redux-actions 를 사용하는 것보다 이 논리를 직접 작성하는 것을 선호합니다.

Imho 디스패치된 작업 스트림을 관찰하기 위한 기본 제공 메커니즘( subscribe 의 콜백 인수?)이 있어야 합니다(미들웨어에서 수행할 수 있다는 것을 알고 있지만 사용할 수 없기 때문에 사용 사례가 상당히 제한적입니다. 외부, 즉 구성 요소 또는 connect )

나는 종종 redux를 다른 사람들에게 가르치는데 다음과 같은 이유로 상당히 어려울 수 있습니다.

• 많은 움직이는 부분: 저장, 상태, 감속기, 작업 생성자, 작업, 비동기 작업, 미들웨어, 연결된 구성 요소
• 도서관. REST API와 통신하는 간단한 앱의 경우 redux, react-redux, redux-thunk(또는 기타) + 테스트하려는 경우 추가 라이브러리가 필요합니다.
• 코드를 넣어야 하는 위치의 양(_움직이는 부분_ 참조)

나는 redux가 그 자체로 총체적으로 의미가 있는 훌륭한 라이브러리라고 생각하며, 그것이 훌륭한 추상화를 가지고 있고 올바르게 사용될 때 확장성이 매우 뛰어나다고 생각합니다. 또한 redux는 모든 UI 라이브러리와 함께 사용할 수 있지만 대부분의 경우 반응과 함께 사용될 것이라고 생각합니다.

일반적으로 많은 좌절감이 움직이는 부분에서 비롯된다고 생각합니다.

제가 가졌던 몇 가지 생각이 있습니다. 이 모든 것은 redux 위에 구축될 수 있으므로 그대로 유지될 수 있습니다.

• 내장된 비동기 작업에 대한 지원과 함께 추가로 제공되는 react redux와 같은 라이브러리를 제공합니다.
• 많은 비동기 작업이 REST API와 통신하므로 이에 대한 관용적 미들웨어를 제공합니다.
• 연결을 사용하는 대신 스마트 구성 요소를 실제 구성 요소로 작성하십시오. 그런 다음 render 메서드에서 멍청한 구성 요소를 렌더링할 수 있습니다.
• _container components_, _smart components_, _dumb components_, _action creators_ 및 _reducers_에 대해 확장 가능한 파일 레이아웃을 규정합니다.
• redux action loadUsers 같은 코드를 생성하려면 _redux-cli_를 제공하세요.
• redux-saga 또는 redux-observable과 같은 비동기 계층에서 표준화하고 문서에 포함합니다(대부분의 redux 문제에 대해 상담할 _one_ 장소가 있으면 좋을 것입니다)
• 기본적으로 확장 언어 기능(예: 데코레이터(@connect)) 또는 TypeScript를 사용하여 특정 mapStateToProps 및 mapDispatchToProps(mobx에는 데코레이터가 필요하고 구문은 간단함)에서 덜 장황하게 만듭니다.

NS

동의합니다. redux-actions 는 상용구를 제거하는 몇 가지 간단한 추상화의 좋은 예입니다.

이렇게 묻겠습니다. Create-React-App에는 미리 빌드된 Babel 및 Webpack 구성이 포함된 react-scripts 패키지가 있으며 합리적인 기본값이 많이 내장되어 있습니다. 해당 redux-scripts 패키지는 어떻게 생겼습니까?

redux-thunk 대한 다른 (부정적인) 의견에 동의합니다. 초보자에게는 권장하지 않습니다(더 이상 권장하지 않을 것입니다).

1. 마법이 시작되는 것 같습니다.
2. 그것은 실제로 많은 보일러 플레이트를 제거하지 않습니다. 더 복잡한 비동기 프로세스가 주어지면 props에서 dispatch 를 가져와 전달해야 하는 것은 코드의 작은 부분일 뿐입니다.
3. 그 결과 더 큰 워크플로로 함께 구성할 수 없는 작업 작성자가 생성됩니다.
4. redux 스타일을 라이브러리보다 프레임워크에 가깝게 만드는 것에 대해 잘 설명할 수 없는 마지막 요점: 라이브러리를 호출하는 대신 프레임워크에 의존하여 코드를 호출합니다.

React-Native 응용 프로그램에서 꽤 많이 사용했고 대부분 유용했지만 redux-thunk 작업 생성자가 void 효과적으로 반환하기 때문에 작업을 함께 구성하는 데 문제가 있었습니다("로그인 성공 후 프로필 로드" 참조)

그것은 사람들이 "무엇이든 할 수 있는 유일한 방법은 React 이벤트 핸들러/콜백에서 즉시 dispatch 하는 것"이라고 생각하도록 부추기는 경향이 있습니다. 그리고 connect from react-redux 하고 mapDispatchToProps 에 크게 의존했기 때문에 이벤트 핸들러 가 일반 함수일

(위의 애플리케이션은 대부분 작년 초에 작성되었으며 더 큰 Redux 생태계에서 무슨 일이 일어나고 있는지 제대로 파악하지 못했기 때문에 최신 버전이 아닐 수 있습니다.)

@bodhi : 접선의 _너무_ 많이 진행하지 않고, 나는 그 결론들 중 일부에 동의하지 않을 것입니다. redux-thunk 는 11 줄이며 "Thunk가 무엇인가요?" 와 같은 멋진 설명 Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability 에서 thunks(그리고 어느 정도는 sagas)의

일부 가상 추상화 계층에서 부작용을 처리하는 _some_ "축복받은" 또는 "내장된" 방법이 필요하다는 데 동의합니다. Sagas와 Observable은 둘 다 훌륭합니다. 사용 방법을 이해한다면 _if_입니다. 여기의 잠재적인 목표가 Redux를 배우고 사용하는 쉬운 경로를 제공하는 것이라는 점을 감안할 때 적절한지 모르겠습니다.

redux-thunk 를 사용하는 것은 비동기적으로 수행하는 것뿐만 아니라 현재 상태에 따라 달라지는 작업을 수행하는 것이기도 합니다. 매우 깨끗하고 간단한 인터페이스로 액션 생성자의 사용을 권장합니다.

Bodhi: 주제에서 조금 벗어난 것일 수도 있지만, dispatch가 void를 반환하지 않고 내부 함수의 결과를 반환한다는 점을 언급할 가치가 있다고 생각했습니다. 따라서 예를 들어 약속을 반환하면 작업을 쉽게 연결할 수 있습니다. 읽어보기에서 구성에 대한 섹션을 참조하십시오.
https://github.com/gaearon/redux-thunk/blob/master/README.md

그 외에 이 공개 토론을 제공한 커뮤니티에 감사의 말을 전하고 싶습니다. 모든 사람의 생각과 아이디어를 듣는 것이 매우 흥미롭습니다.
개인적으로 지금까지 썽크를 고수했지만 "무슨 일이 일어났는지"와 "상태가 어떻게 변경되어야 하는지"를 명확하게 구분하려고 합니다. 나는 우리 코드에서 우리가 실수를 하는 꽤 많은 경우를 봅니다(리듀서가 무슨 일이 일어났는지 반응하는 대신에 무엇을 해야할지 알려주는 액션을 사용) do (아직 sagas에서 판매되지 않음).

2017년 3월 19일 23:48에 Bodhi [email protected]이 다음과 같이 썼습니다.

redux-thunk에 대한 다른 (부정적인) 의견에 동의합니다. 초보자에게는 권장하지 않습니다(더 이상 권장하지 않을 것입니다).

마법이 시작되는 것 같습니다.
그것은 실제로 많은 보일러 플레이트를 제거하지 않습니다. 더 복잡한 비동기 프로세스가 주어지면 소품에서 디스패치를 ​​가져와 전달해야 하는 것은 코드의 작은 부분일 뿐입니다.
그 결과 더 큰 워크플로로 함께 구성할 수 없는 작업 작성자가 생성됩니다.
redux 스타일을 라이브러리보다 프레임워크에 가깝게 만드는 것에 대해 잘 설명할 수 없는 마지막 요점: 라이브러리를 호출하는 대신 프레임워크에 의존하여 코드를 호출합니다.
React-Native 애플리케이션에서 꽤 많이 사용했고 대부분 유용했지만 redux-thunk 액션 생성자가 효과적으로 void(즉, 다음 작업의 순서를 지정하는 데 사용할 약속과 같은 것은 없습니다.

사람들이 "무엇이든 할 수 있는 유일한 방법은 React 이벤트 핸들러/콜백에서 즉시 전달하는 것"이라고 생각하도록 부추기는 경향이 있습니다. 그리고 react-redux의 connect를 사용하고 mapDispatchToProps에 크게 의존했기 때문에 이벤트 핸들러가 일반 함수일 수 있다는 사실을 잊어버리는 경향이 있었습니다.

(위의 애플리케이션은 대부분 작년 초에 작성되었으며 더 큰 Redux 생태계에서 무슨 일이 일어나고 있는지 제대로 파악하지 못했기 때문에 최신 버전이 아닐 수 있습니다.)

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

(탄젠트를 계속해서 죄송하지만...)

디스패치는 void를 반환하지 않고 내부 함수의 결과를 반환한다는 점을 언급할 가치가 있습니다.

허, 대단해! 문제를 해결하기 위한 다른 방법을 찾기 전에 문서를 너무 자세히 살펴본 적이 없는 것 같습니다.

Redux를 훨씬 쉽게 만들어준 가장 가치 있는 것 중 하나는 작업을 명령이 아닌 이벤트 로 취급한다는 것입니다. 이렇게 하면 작업을 디자인하는 방법과 작업에 넣을 내용을 결정하는 데 어려움을 겪지 않습니다.

구성 요소가 사용자 상호 작용 상태에 영향을 미치는 방법을 알 필요가 없습니다, 그들은 단지, 예를 들면 "버튼 X를 클릭"그 안에 있었나요 무엇을 외부 세계를 말한다. 작업을 명령으로 사용할 때 구성 요소와 상태 간에 양방향 바인딩을 효과적으로 도입합니다.

리듀서는 구성 요소에 바인딩되지 않으며 구성 요소 상태가 아닌 애플리케이션 상태 를 나타내며 어떻게 변경 "상태로 무엇을 할 것인가" 라는 문장이 아니기 때문에 여러 리듀서에서 단일 액션을 처리하는 데 인지적 장벽이 없습니다.

이렇게 하면 여러 작업을 동기적으로 디스패치하는 경우도 제거됩니다.

여러 위치에서 단일 작업을 전달하는 경우도 사라집니다. 작업 생성자를 구성 요소 근처에 두어 작업을 전달한 구성 요소를 쉽게 추적할 수 있습니다.

DevTools의 작업 로그를 보면 앱 내부에서 발생한 일 의 전체 기록을 볼 수 있으며 작업의 영향을 받는 구체적인 상태 조각을 쉽게 볼 수 있습니다. 역사는 가능한 한 가장 짧습니다.

이 풀 기반 접근 방식은 데이터 흐름을 진정한 단방향으로 만들고 redux-saga 또는 redux-observable 와 같은 부작용 관리 라이브러리와 자연스럽게 스택합니다.

@aikoven 이 말에 전적으로 동의하지만(과거에는 redux를 이벤트 소싱과 비교하는 데 확실히 많은 토론이 있었습니다), 매우 일반적으로 볼 수 있는 FETCH_USER 와 같은 것으로 무엇을 합니까? 수행해야 함). 그것은 "이벤트와 같은"보다 "명령과 같은"것 같습니다.

@blocka 네트워크 요청으로 FETCH_USER_STARTED 및 FETCH_USER_DONE / FETCH_USER_FAILED 작업으로 래핑될 수 있으며, 이것이 요청 결과가 상태로 끝나는 방식입니다.

👍 redux-actions

상용구를 줄이는 것 외에도 내가 좋아하는 것은 redux의 매우 자연스러운 확장처럼 느껴진다는 것입니다. jumpstate 같은 경우 구현이 조금 더 멀어지고 있다고 느끼고 이제 하나가 아닌 두 가지를 배워야 합니다.

그래서 제 요점은 보일러 플레이트를 줄이기 위해 추가하는 모든 플러그인이 덜 장황한 API를 사용하더라도 redux로 작업하는 것과 매우 흡사해야 한다는 것입니다.

많은 상용구는 모든 환경에 있는 것과 동일한 상용구입니다. 중복이 발생하면 일반적으로 사용자 정의 추상화로 해결합니다. 이러한 추상화는 현재 프로젝트 외부에서는 유용하지 않은 경우가 많으며 "은색 총알"은 존재할 수 없습니다. 모든 프로젝트의 요구 사항은 다릅니다.

redux도 마찬가지입니다. FETCH_X_STARTED 액션과 fetchX() 액션 생성기, 그리고 이를 처리하는 리듀서 등이 필요하다면 자유롭게 추상화를 만들어 보세요!

상용구에 대한 redux를 비난하는 것은 모든 코드를 복사하여 붙여넣은 다음 너무 많은 상용구를 가지고 있는 자바스크립트를 비난하는 것과 같습니다.

redux-thunk를 사용하는 것은 비동기적으로 수행하는 것뿐만 아니라 현재 상태에 따라 달라지는 작업을 수행하는 것이기도 합니다. 매우 깨끗하고 간단한 인터페이스로 액션 생성자의 사용을 권장합니다.

동기 코드에 redux-thunk를 사용하는 것은 좋은 생각이 아니며 문서에서 언급해야 합니다.
많은 기능을 함께 구성하면 디스패치 흐름이 순서에 의존하지 않는다는 것을 확신할 수 없으므로 추론하고 테스트하기가 더 어렵습니다.

순수한 액션 생성자가 있고 더 복잡한 상태 수정을 위해 단순히 액션 일괄 처리를 사용하는 것이 더 나은 것 같습니다. 이렇게 하면 테스트할 순수 함수만 갖게 됩니다.

더 나은 이해를 위해 이 블로그 게시물을 추천합니다. http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/

@Machiaweliczny 기사에 감사드립니다. 제 질문은 비즈니스 로직을 어디에 두는가에 대한 것입니다( https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a-에서 논의됨). react-redux-application-9253ef91ce1#.3ce3hk7y0). 디스패치 흐름(thunk, epic, saga 등)이 현재 응용 프로그램 상태에 절대 액세스할 수 없어야 한다고 말하는 것이 아닙니다. 그렇죠?

@dfbaskin

Redux는 도메인 기반 개발이 아님을 명심하십시오. "비즈니스 논리"는 여기에서 훨씬 모호한 관심사이며 "어떤 개념의 기능 서명이 내가 구현하려는 논리에 가장 잘 맞는지"입니다. 귀하의 "비즈니스 로직"은 귀하가 필요로 하는 것에 따라 선택기, 감속기, 작업 생성기 및 "오케스트레이터"(이에 대해 더 나은 단어가 아직 있습니까?)에 걸쳐 분산되어 있습니다.

(state, action) => state 감속기는 일반적으로 "상태에 의존하는 논리"가 있어야 하는 곳입니다. 그리고 확실히 Elm Architecture와 같은 것에서 이러한 모든 논리는 "업데이트" 기능(우리의 감속기와 동일)에 있습니다.

불행히도 Redux에서 감속기는 동기 논리만 처리할 수 있습니다. 따라서 상태에 의존하는 비동기식 "비즈니스 로직"은 디스패치(구성 요소에 해당 정보가 있는 경우 항상 그런 것은 아님)를 통해 구성 요소에서 가져오거나 선택한 오케스트레이터 개념(thunk, sagas, epic)을 통해 가져와야 합니다. 이를 위해 상태에 액세스할 수 있습니다.

감속기의 한계가 아니었다면 그럴 필요가 없었을 것입니다. 사람들이 redux-saga 또는 redux-observable을 사용할 때 실제로 그것을 볼 수 있습니다. 그들의 액션/액션 생성자는 일반적으로 거의 사소해지며(대부분의 경우 정규화 또는 형식화에 플러스 또는 마이너스), 사가/에픽은 거의 "대체 리듀서"입니다. , 이제 액션과 상태에 액세스하고 "사물"을 반환하는 또 다른 것이 있으며 결과적으로 실제 감속기의 복잡성이 줄어듭니다. 리듀서와 오케스트레이터는 매우 밀접하게 관련되어 있습니다.

@Machiaweliczny : "

더 좋은 토론이지만 우리는 주제에서 조금 벗어나기 시작했습니다. (저쪽에 보이는 자전거 보관소인가요? :) )

원래 질문으로 돌아가 보겠습니다.

• "적은 상용구"를 사용하는 관용적 Redux 사용법은 무엇입니까? 이러한 불만 사항에 대한 솔루션을 어떻게 제공할 수 있습니까?
• 학습 및 사용 프로세스를 단순화하지만 실제로 Redux를 숨기지 않고(그리고 "기본" Redux로의 마이그레이션/학습 경로를 제공할 수 있는) 가능한 추상화를 만들 수 있습니까?
• 어떤 식으로든 개선된 문서로 이 문제를 얼마나 해결할 수 있습니까?

이러한 문제를 해결하기 위해 어떤 구체적인 단계를 구현할 수 있습니까?

논쟁의 여지가 없고 실행 가능한 단기 단계의 영역에서 저는 다음과 같이 말하고 싶습니다.

1) 스토어를 더 쉽게 구성할 수 있도록 합니다(기본 구성일 수도 있나요? 여전히 그런 것인지는 모르겠지만 Elm에는 "스타터 앱" 유형과 일반 앱 유형이 있었습니다. 스타터 앱이 사용되었습니다. 간단한 앱과 교육 자료에서 사람들이 막 배우는 경우의 90%를 커버하기 위해 지금까지 서명에 대한 문서를 검색하지 않고 기본 미들웨어(devtools, thunks)로 Redux 스토어를 구성할 수 없다는 것을 인정합니다. 나는 많은 사람들이 신규 이민자들이 Redux 핵심 개념을 배우기 위해 상점의 미들웨어를 구성하는 방법을 알아야 한다고 주장하지 않을 것이라고 생각합니다.

2) 이것은 이미 해당될 수 있습니다. create-react-app에 위의 "스타터 스토어"와 함께 Redux를 추가하는 것이 가능한 한 쉬운지 확인하여 신규 사용자가 2분 안에 Redux 앱을 실행하고 실행할 수 있도록 하십시오.

나는 이것이 우리를 아주 멀리 데려갈 것이라고 생각합니다.

편집: 스타터 앱이란 앱 상용구를 의미하는 것이 아니라 구성할 수 없지만 사람들이 가져오고 완료할 수 있는 합리적인 기본값이 있는 "createStore"를 의미합니다. 그런 다음 성장하면 "실제" createStore로 이동할 수 있습니다.

그것은 바로 거기에서 꽤 환상적인 개념처럼 들립니다.

2017년 3월 20일 월요일 오전 10:02 Francois Ward [email protected]
썼다:

논쟁의 여지가 없고 실행 가능한 단기 단계의 영역에서 저는 다음과 같이 말하고 싶습니다.

1.

저장소를 더 쉽게 구성할 수 있도록 합니다(기본적으로
구성? 지금도 그런지는 모르겠지만 느릅나무는
"스타터 앱" 유형 및 일반 앱 유형. 스타터 앱은 다음 용도로 사용되었습니다.
사람들이 90% 경우를 커버하는 간단한 앱과 교육 자료에서
그냥 학습. 지금까지 Redux 스토어를 구성할 수 없음을 인정합니다.
문서를 검색하지 않고 기본 미들웨어(devtools, thunks)를 사용하여
서명. 나는 많은 사람들이 새로운 이민자가 필요하다고 주장하지 않을 것이라고 생각합니다.
Redux 코어를 배우기 위해 상점의 미들웨어를 구성하는 방법을 알고
개념.
2.

이것은 이미 경우일 수 있습니다. 위의 내용으로 Redux를 추가해야 합니다.
react-app을 생성하는 "스타터 스토어"는 가능한 한 간단하므로 초보자
2분 안에 Redux 앱을 실행하고 실행할 수 있습니다.

나는 이것이 우리를 아주 멀리 데려갈 것이라고 생각합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
.

우리 모듈은 combineReducers 를 사용하여 모듈의 각 상태 슬라이스에 전용 리듀서를 갖습니다(이 접근 방식은 "슬라이스 리듀서"라고도 하는 문서의 구조화 리듀서 섹션에 설명되어 있다고 생각합니다). 이것은 switch 문이 훨씬 더 작기 때문에 상황을 더 쉽게 추론할 수 있습니다. 또한 코드 기반 전체에 공통 리듀서가 등장할 수 있었습니다. 가장 단순한 리듀서는 액션 유형을 제외하고 모듈에서 동일하므로 액션 유형별로 이러한 리듀서를 만드는 도우미 기능(리듀서 팩토리?)을 사용하여 상용구를 줄일 수 있었습니다.

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

아마도 이와 같은 더 일반적인 슬라이스 리듀서를 식별하는 것은 우리 리듀서의 기본 빌딩 블록으로 사용될 수 있는 상용구 문제를 완화하는 좋은 방법이 될 것입니다.

이것은 기본적인 자바스크립트 리팩토링입니다. 내가 전에 말했듯이 ... "자바 스크립트"에는
코드에 추상화와 같은 것을 적용할 때까지 많은 "보일러 플레이트".

Redux는 자바스크립트일 뿐입니다. 그것에 대해 마법 같은 것은 없습니다.

2017년 3월 20일 월요일 오후 12시 44분, Markus Coetzee [email protected]
썼다:

우리 모듈은 CombineReducers를 사용하여 각 상태 슬라이스가
모듈에는 전용 감속기가 있습니다(이 접근 방식이 설명되어 있다고 생각합니다.
문서의 Structuring Reducers 섹션에서 "슬라이스
감속기"). 이렇게 하면 스위치가
진술은 훨씬 적습니다. 또한 일반적인 감속기가 등장하도록 허용했습니다.
우리의 코드 기반 전반에 걸쳐. 가장 단순한 감속기는 모듈 간에 동일했습니다.
액션 유형을 제외하고 다음과 같이 상용구를 줄일 수 있었습니다.
이러한 리듀서를 만드는 도우미 기능(리듀서 팩토리?)이 있습니다.
행동 유형별:

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';
const searchModule = CombineReducers({
검색: makeIndicator(c.SEARCH),
결과: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

아마도 이와 같은 더 일반적인 슬라이스 리듀서를 식별하는 것이 좋을 것입니다.
상용구 문제를 완화하는 방법
감속기를 위한 기본 빌딩 블록입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
.

상용구 감속기를 개발하는 것보다 일반적인 redux 패턴을 설명하는 것이 더 낫다는 대부분의 의견에 동의합니다. 제 팀원들과 저는 1.5년 전에 redux로 작업하기 시작했고 가장 단순한 것들에 대해 혼란스러워했습니다. redux는 대부분 이벤트 소싱이고, 동일한 작업을 여러 리듀서에서 처리할 수 있으며, 해당 작업에는 id 뿐만 아니라 전체 비즈니스 개체가 포함될 수 있습니다. , 감속기는 기능일 뿐이며 작성, 생성, 분할 등 원하는 모든 작업을 자유롭게 수행할 수 있습니다. 원격 명령으로 작업을 사용하고 고전적인 메서드 호출을 사용하지 않는 이유를 궁금해하는 일반적인 실수를 했습니다. 거대한 미들웨어를 만들고 "제너레이터가 너무 복잡하기 때문에"(redux-saga는 훌륭하지만!) redux-saga를 피하고 거대한 스위치로 긴 파일을 만들었습니다. 이것은 물론 평범한 프로그래밍 기술 때문이기도 하지만 구조화된 정보가 부족하기 때문이기도 합니다. 오늘 문서는 훨씬 더 나아졌습니다. 유지 보수자들 덕분입니다!

이것은 라이브러리로서의 Redux에 대한 매우 귀중한 주제입니다.

이것은 기본적인 자바스크립트 리팩토링입니다. 내가 전에 말했듯이 ... "자바 스크립트"에는
코드에 추상화와 같은 것을 적용할 때까지 많은 "보일러 플레이트".
Redux는 자바스크립트일 뿐입니다. 그것에 대해 마법 같은 것은 없습니다.

완벽해, @blocka! 이 메시지는 널리 퍼질 필요가 있다고 생각합니다.

Redux는 최소한의 접근 방식 때문에 사람들에게 독특하고 상용구 같은 느낌을 줍니다. Minimal은 일반적으로 "프레임워크"에 대해 이상하게 느껴집니다(최소 코드, 최소 원칙).

어떤 사람들은 JavaScript 자체를 작성하는 것보다 "framework-y" 코드를 작성하는 데 익숙합니다. 개발자가 프레임워크를 사용할 때 기본 제공 방식이 암시적으로 예상됩니다. 지옥처럼 슬프지만 사실입니다.

Redux가 그 어느 때보다 시작하기 쉬워지고 있다고 생각하지만 Redux가 모든 것을 할 것이라고 기대하지 않는다는 점을 분명히 해야 합니다. @gaearon 은 항상

어제 그것에 대한 짧은 기사를 썼습니다. React나 Redux를 탓하지 마십시오 . 물론 나는 이 모든 것에 대해 틀릴 수 있다.

고급 라이브러리 위에 추상화 계층을 갖는 선례가 있습니다. 최근 Tensorflow는 핵심 API( http://www.fast.ai/2017/01/03/keras/) 위에 Keras를 추상화로 도입했습니다

TensorFlow를 사용하면 내가 TensorFlow를 사용할 만큼 똑똑하지 않다는 느낌이 듭니다. Keras를 사용하면 신경망이 생각보다 쉽다는 느낌이 듭니다. 이것은 TensorFlow의 API가 장황하고 혼란스럽고 Keras가 내가 경험한 것 중 가장 사려 깊게 디자인되고 표현력이 풍부한 API를 가지고 있기 때문입니다. 나는 처음 몇 차례의 실망스러운 상호 작용 후에 TensorFlow를 공개적으로 비판하기에는 너무 창피했습니다. 너무 투박하고 부자연스럽게 느껴졌지만 이것은 확실히 내 실패였습니다.

Redux를 처음 접하는 대부분의 사람들에게 비슷한 경험이라고 생각합니다. Tensorflow 를 Redux , Keras 를 Jumpstate 바꿉니다. Redux는 매우 강력하지만 대부분의 사용자는 사용 가능한 모든 컨트롤이 필요하지 않을 수 있습니다. 아마도 그들은 Angular에서 오고 있거나 부트캠프에서 React + Redux를 배우거나 다양한 튜토리얼을 보고 있을 것입니다. Redux는 신규 사용자를 위해 덤덤해질 필요는 없지만 잠재적 사용 사례의 80%를 커버할 수 있는 더 쉬운 추상화를 제공하는 것도 안티 패턴이 아닙니다.

여러분, redux가 있는 그대로 괜찮았다면 이런 대화를 나누지 않았을 것입니다. redux가 유용하거나 구조적으로 건전한지 여부에 관계없이 사람들은 처음 배울 때 여전히 "나쁘다"고 느낍니다. 이러한 감정은 유효합니다.

이 스레드에 댓글을 다는 사람들은 모두 redux 전문가입니다. 물론 우리는 redux에 만족합니다. 우리는 그 철학을 내면화했으며 "보일러 플레이트"를 관리하기 위해 자신의 추상화를 만드는 것이 편안합니다. 우리는 이 스레드가 제공하려는 청중이 아닙니다. redux를 처음 사용하는 사용자, 함수형 프로그래밍을 처음 접하는 사용자에게 약간의 공감 이 필요합니다.

예를 들어: 다음은 redux에 대해 자주 듣는 불만입니다(업스레드에 대해 언급되지 않은 것 같습니다): redux를 사용하는 것만으로는 충분하지 않습니다. react-redux, redux-thunk, redux-actions 등도 사용해야 합니다. .

말 그대로 redux를 사용하기 위해 다른 모든 패키지를 사용해야 합니까? 아니요.
대부분의 redux 사용자는 이러한 추가 패키지의 일부 또는 전체를 사용하게 됩니까? 예.

package.json 의 패키지 수가 중요합니까? 아니 정말.
package.json 의 패키지 수가 사람들의 기분에 영향을 줍니까? 전적으로.

이제 redux 자체는 그대로 유지되어야 하고 다른 패키지( create-redux-app 또는 무엇이든)가 이들을 함께 조립해야 한다고 믿는 것이 타당하다고 생각합니다. 그러나 우리는 실제로 복잡한 문제를 가지고 있으며 사용자에게 RTFM에 알리는 것만으로는 충분하지 않습니다.

redux가 유용하거나 구조적으로 건전한지 여부에 관계없이 사람들은 처음 배울 때 여전히 "나쁘다"고 느낍니다. 이 감정은 유효하다

전적으로. 그러나 모든 사람들이 그렇게 느끼는 것은 아닙니다. 일부는 그렇습니다. 문제가 없는 사람들의 이야기는 절대 듣지 못할 것임을 명심하십시오. 질문을 하거나 stackoverflow/reactiflux를 누르는 사람만 볼 수 있습니다. 한 번도 해보지 않은 사람들 중 일부는 도움이 필요하지만 어떻게 요청해야 할지 모르는 경우도 있습니다... 그리고 일부는 잘 지내고 있습니다. 당신은 그들을 더 나쁘게 만들고 싶지 않습니다... 그렇지 않으면 그들은 그렇게 할 것입니다. 대신 포럼에 오는 사람이 되며 순 제로 이득이 될 것입니다.

Redux는 아무 이유 없이 인기를 얻지 못했습니다. 정말 많은 분들이 맛있다고 하셔서 다른 분들께도 추천해 주셨어요 :)

이제 redux 자체는 그대로 있어야 하고 다른 패키지(create-redux-app 또는 무엇이든)가 함께 조립해야 한다고 믿는 것이 타당하다고 생각합니다.

이 아이디어가 마음에 들었습니다. 기존의 상용구가 이미 해결했다고 주장하는 것도 가능하지만, React에 입문하려고 할 때 도구에 압도되는 것에 대해 사람들이 불평하던 당시 React에도 상용구가 많았습니다. create-react-app 는 이 모든 것에 대한 훌륭한 답변이었습니다. 왜냐하면 초보자가 이미 React _자체_에 입문하기 위한 많은 단계를 제거했기 때문입니다.

그러나 그것은 후드 아래에서 여전히 상용구입니다. 따라서 우리는 여전히 사람들이 생태계를 구매하도록 장려하고 Redux 자체가 의도적으로 많은 것을 하지 않는다는 것을 분명히 해야 합니다 . React나 Redux를 사용하고 싶다면 생태계에서 도망칠 수 없습니다.

Redux 코어에 redux-thunk 와 같은 패키지를 포함하는 것이 여기로 가는 길이라고 생각하지 않습니다.

명확성을 위해 내가 던지고 있는 아이디어의 종류는 실제로 핵심에 직접 포함하는 것에 관한 것이 아닙니다. 그들은 create-react-app 라인을 따라 별도의 패키지 또는 CLI 도구 또는 기타가 될 일종의 "사전 구축된 구성" 또는 "사용 용이한 추상화 계층"을 가상적으로 생성하는 것입니다.

나는 Jumpstate/Jumpsuit의 저자로 차임하는 것이 더 낫다고 생각합니다.

TL;DR:
Redux는 너무 낮은 수준이기 때문에 배우기 어렵고 구성/통합하기 어렵습니다. 커뮤니티는 90% 사용 사례를 목표로 하는 표준화된 상위 수준 redux API의 이점을 활용하여 학습 곡선을 용이하게 하고 더 간단한 프로젝트를 위한 솔루션으로 운영할 수도 있습니다. Jumpstate는 이를 해결하기 위해 노력하고 있지만 장기적인 해결책은 아닙니다. 우리는 이 API가 어떻게 보일지에 대한 가능한 아이디어(실제 또는 메타 코드)를 제안하기 시작해야 합니다.

Redux는 처음부터 배우기가 매우 어렵고 비동기 로직, 부작용, 사용자 정의 미들웨어 등과 같은 새로운 개념과 통합하기가 매우 어렵습니다. 리액트 생태계에 아주 새로운 것이었습니다.

반응을 배우고 며칠 만에 나는 즉시 redux를 배우도록 권장되었습니다. 이 권장 사항은 동일한 작업을 수행한(또는 수행 중인) 매우 경험이 많은 개발자와 초보 개발자 모두에게서 나온 것입니다. setState 이상으로 확장된 모든 것에 대한 사실상의 솔루션으로 환영받았습니다(setState 게이트는 여기서 제외합시다 😉 ). redux가 훌륭하기 때문에 이 모든 것은 정당한 이유가 있습니다.

나는 불가피하게 학습 곡선에 부딪혔고 도움을 구했을 때 Redux에 대한 마케팅 및 문서화된 접근 방식이 "Redux는 어렵고 개념은 저수준이며 API는 잠겨 있으며 전원을 켜면 됩니다. 그것."

이것이 내가 모든 동료들과 함께 한 일입니다. 그것이 우리가 하도록 교육받은 것이기 때문에 우리는 그것을 통해 힘을 얻었습니다. 그러나 이 여정을 따라 나는 redux가 제공해야 하는 복잡성과 고급 기능 중 일부를 일시적으로 의도적으로 숨기는 추상화 계층을 아주 초기에 만들려고 했습니다.

나는 커스텀 액션 생성자가 필요하지 않았고, 액션과 디스패처를 컴포넌트에 매핑하는 것에 대해 걱정하고 싶지 않았고, 다른 많은 사람들과 마찬가지로 switch 문 대신 덜 장황한 리듀서 레이아웃을 선택했습니다.

그것은 환상적으로 작동했습니다. 사실, 다른 동료들과 학습 곡선으로 비슷하게 고군분투하는 다른 개발자들을 위해 redux를 배우는 과정을 가속화했습니다.

우리는 고급 또는 "관용적" redux가 필요할 때 계속 사용할 수 있도록 설계했지만 실제로 90% 사용 사례에 맞게 설계했습니다.

결코 jumpstate가 모든 기반을 포괄한다고 말하는 것이 아닙니다. 실제로 jumpstate가 "관용적으로" 작동하려면 변경해야 할 사항이 너무 많습니다(사용자 지정 가능한 작업 생성기, 전역 작업 가져오기 제거... 많이) 하지만 많은 사람들이 기본을 배우는 데 확실히 도움이 되었고 매우 간단한 수준에서 redux가 작동하는 방식을 이해할 수 있는 경로를 제공했습니다. 나는 항상 Jumpstate가 누군가가 redux를 배우는 데 도움이 되었다는 메시지를 Jumpstate slack 조직에서 받습니다.

그 사람들이 오늘날에도 여전히 jumpstate를 사용하고 있는지 여부는 그다지 중요하지 않습니다(그러나 많은 사람들이 오늘날에도 여전히 그것을 프로덕션에서 사용하고 있습니다). 중요한 것은 그들이 가진 경험과 redux 생태계에서 얼마나 빨리 생산성을 발휘할 수 있었는지였습니다.

이 토론에 대해 생각나는 몇 가지 아이디어:

• 단순화된 redux가 어떻게 보이는지에 대한 메타 예제를 제안하고, 한 번 찔러보세요!
• 자주 복제되고 매우 독단적인 redux middlewars에 대한 요구 사항을 논의하고 표준을 결정합니다. 비동기 처리로 시작할 수 있습니다. 이것은 redux 커뮤니티의 많은 단편화를 해결할 수 있고 모두의 노력이 redux의 장기적인 생존과 사용에 변화를 가져오는 데 도움이 될 수 있습니다.

어떤 식으로든 개선된 문서로 이 문제를 얼마나 해결할 수 있습니까?

많이. Redux 문서에 관해서는 AngularJS와 마찬가지로 불필요하게 장황하지만 AngularJS와 달리 "표시하고 말하지 않기" 원칙에 실패하기 때문에 AngularJS 1의 문서보다 훨씬 더 나쁘다고 생각합니다.

Redux의 문서는 코드의 실제 데모보다 코드 스니펫을 선호합니다. 즉, "여기에 코드 세트가 있습니다. 연결 방법은 말하지 않겠지만 작동한다는 것을 믿으십시오"라는 순간이 너무 많습니다. 브라우저 내에서 예제를 실행할 수 있는 능력이 없다는 것은 사용자가 로컬에서 하는 일이 제대로 작동하고 무언가가 작동하지 않으면 스스로 꺼진다는 자신의 본능을 믿어야 한다는 것을 의미합니다. 간단한 Todo List 앱조차도 Redux의 "hello world" 최고의 예는 아니라고 생각합니다. 훨씬 간단하게 만들 수 있습니다.

여기에 다이어그램이 확실히 도움이 될 것입니다. 예를 들어, 나는 @sunjay 의 것을 좋아합니다. 더 나은 방법은 파일이 어떻게 연결되어 있는지 등 높은 수준의 보기에서 할 일 목록 예제 자체를 위해 디자인하는 것입니다. 이미지는 긴 텍스트를 전달하는 데 거의 항상 더 좋으며 문서의 장황함을 줄이는 데 도움이 될 수 있습니다. 이미지는 또한 초보자가 초점을 유지하고 Redux를 전체적으로 더 잘 이해하는 데 도움이 됩니다.

내 두 센트: 코어를 변경하지 마십시오. 그 광채는 단순함에 있습니다. 이 시점에서 무언가를 추가하면 전체에서 제거될 수 있습니다.

사용자 친화성과 추가 추상화는 사용자 영역에서 발생할 수 있습니다. 공식적으로나 관용적으로 사용할 필요가 없다고 생각합니다. 예측 가능한 상태 컨테이너입니다.

설 수 있어 Let's be be ❤️

즉, 그 위에 더 많은 의견이 있는 라이브러리를 만들어 원하는 대로 패키지로 만들 수 있습니다. 저도 그렇긴 한데 코어는 바꾸지 맙시다, 제발요.

@HenrikJoreteg , 두려워하지

많이. Redux 문서에 관해서는 AngularJS와 마찬가지로 불필요하게 장황하지만 AngularJS와 달리 "표시하고 말하지 않기" 원칙에 실패하기 때문에 AngularJS 1의 문서보다 훨씬 더 나쁘다고 생각합니다.

이것은 매우 사실입니다. Redux가 새로 나왔을 때 한 가지는 문서가 드물었지만 기본 사항은 있었다는 것입니다. 많은 사람들이 "너무 간단"해서 채택했습니다. 그러나 온라인 리소스는 이제 "내가 가장 좋아하는 미들웨어"와 "내가 가장 좋아하는 상용구 감소 도구"인 "실제 기술"을 보여주려고 합니다. 사람들은 압도됩니다.

"적을수록 좋다"라는 말이 있습니다.

@Phoenixmatrix , @Sylphony : 그렇다면 잠재적인 문서 개편은 어떤 모습일까요?

개인적으로, "초보자 상점"이 있다는 위의 제안과 결합하기 위해 두 개로 나눕니다(2개의 다른 사이트/문서가 아니라 2개의 다른 섹션).

귀엽고 단순한 그림이 많이 있는 "Redux 아키텍처"는 액션과 리듀서를 설명하고 react-redux와 아마도 썽크를 소개하고 "스타터 스토어"를 사용하여 모든 종류의 선행 구성을 제한하고 얼마나 쉬운지 보여줍니다. 몇 가지 ajax 요청을 수행하고 화면에 내용을 렌더링하는 간단한 앱을 만드는 것입니다.

다른 모든 것은 고급 개념이 포함된 "탐색" 섹션으로 이동할 수 있습니다. 그때도 아마 많은 것을 찢을 것입니다. 오늘 누군가가 나에게 앱에 여러 스토어를 갖는 섹션이 있다고 지적했습니다. 알면 좋은데 그 쓰임새가 정말 고급스럽습니다. 나는 새로운 이민자가 그것을 보지 않고 우연히 발견 할 필요가 있다고 생각하지 않습니다.

더 나은 문서는 항상 좋은 생각이지만 이것이 여기서 핵심 문제를 해결한다고 생각하지 않습니다. Redux API의 상용구와 장황함 때문에 추상화 라이브러리가 작성되고 채택되고 있습니다. 동일한 라이브러리가 특정 수준 또는 다른 수준에서 분명히 필요하기 때문에 Redux 커뮤니티를 조각화하고 있습니다. 생태계에 적극적으로 기여하려고 노력하는 동일한 저자들이 "Redux를 이해하지 못한다"는 이유로 공개적으로 폄하되고 해고될 때 실망스럽습니다. 커뮤니티가 React 코어의 일부가 아니라 어느 정도 "축복받은" 더 간단한 추상화를 만들 수 있다면 모두가 이깁니다. 하드코어 사용자는 Redux를 그대로 사용하고 다른 사람들은 더 쉽고 덜 장황한 API로 추상화를 사용할 수 있습니다.

@derekperkins "축복받은" 도서관에 대한 합의는 어떻게 이루어지나요? 그 안에 들어갈 내용과 작업할 사람을 어떻게 결정합니까?

나는 이것에 모두 찬성하지만 일부 사람들만 사용하는 또 다른 라이브러리를 만들어 생태계를 더욱 분열시키는 것을 피하려면 어떻게 해야 할까요?

관련 xkcd: https://xkcd.com/927/

네, redux의 핵심과 react-redux는 가능한 한 합의에 가깝습니다. redux-thunk와 redux-actions조차도 경계선에 가깝습니다. 그 수준에서도 대다수의 사람들이 필요로 하는 바가 다르기 때문입니다.

Redux에서 상용구를 줄이는 것은 "필요하지 않습니다.그래서 나는 그것을 추상화할 것이다. 하지만 신인이라도 "그 부분"은 극명하게 달라진다.

젠장, 우리는 많은 (수십 개) redux 앱을 가지고 있고, 다른 앱이 다른 요구 사항을 가지고 있기 때문에 공통 상용구 감소 스택을 구축하기가 어렵습니다. 단일 앱 또는 동일한 요구 사항을 가진 몇 개의 앱이 있으면 쉽습니다. 작은 것조차도 꽤 다릅니다.

여기에서 아이디어는 모든 사람들을 위한 모든 문제를 해결하는 툴킷을 구성하는 것이 아닙니다. CRA를 예로 사용: Babel, Webpack 및 ESLint를 구성하는 방법은 무수히 많습니다. CRA가 하는 일은 사용자 측에서 번거로움 없이 모든 작업을 수행할 수 있는 독단적인 단일 방법을 제공하는 것이며, 학습자를 위해 더 나은 환경을 만드는 여러 설정을 의도적으로 선택합니다. 그런 다음 사용자가 _원하는 경우_ 구성을 제어할 수 있습니다.

또한 모든 단일 사용 사례를 해결하려고 하지도 않습니다. CRA는 고급 코드 분할, 다중 진입점, SSR 또는 이와 유사한 것을 다루지 않습니다. CRA 문서 _do_는 더 많은 구성 가능성을 제공하고 특정 사용 사례에 더 잘 작동할 수 있는 다른 도구 및 옵션을 가리킵니다.

좋은 방법입니다. 빨리 일어나서 실행해야 하는 것
redux와 이 가상 구성 레이어만 설치하면 되나요? 저것
굉장할 것입니다.

내가 가진 또 다른 아이디어는 개발자 모드에서 설정할 수 있는 플래그입니다.
사용자를 위한 점진적 학습 기회를 관찰하고 노출합니다. 에
이런 식으로 추상화 계층은 대화형 교육 도구 역할을 할 수 있습니다.
2017년 3월 20일 월요일 오후 4:14 Mark Erikson [email protected]
썼다:

여기에서 아이디어는 모든 문제를 해결하는 툴킷을 구성하는 것이 아닙니다.
모든 사람들을 위해. CRA를 예로 사용: 구성하는 방법이 많이 있습니다.
Babel 및 Webpack 및 ESLint. CRA가 하는 일은 단일한 의견을 제공하는 것입니다.
사용자 측에서 번거로움 없이 모두 작동하도록 하는 방법과
의도적으로 상황을 개선하는 여러 설정을 선택합니다.
학습자. 그런 다음 사용자가 다음과 같은 경우 구성을 제어할 수 있습니다.그들은 원한다 .

또한 모든 단일 사용 사례를 해결하려고 하지도 않습니다. CRA는 시도하지 않습니다.
고급 코드 분할, 다중 진입점, SSR 또는 다음과 같은 문제를 해결합니다.
저것. CRA가 워드 프로세서는 다른 도구 및 제공 할 수 있습니다 옵션에 지점을
더 많은 구성 가능성과 특정 사용 사례에서 더 잘 작동합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
.

@sunjay 클릭하지 않고도 xkcd 링크가 무엇인지 알았습니다. :)

나는 @markerikson에 동의합니다. 이것은 모든 사람에 대한 모든 극단적인 경우를 처리하려는 시도가 아닙니다. 핵심 Redux 개발자가 "이것이 작업을 수행하는 좋은 방법입니다"라고 말하는 독단적인 진술입니다. 필요한 경우 재정의할 수 있는 정상적인 기본값이 있지만 기본값이 개발자의 80%에 대해 작동할 것이라고 장담합니다.

핵심 Redux에 작성되거나 작성되지 않을 수 있습니다. 나는 여전히 학습 곡선을 가속화하는 것 이상을 수행하는 Jumpstate와 같은 곳이 있다고 생각합니다.

Redux 학습 곡선은 가파르지만 개념을 이해하면 추상화 계층의 필요성이 사라집니다.

어느 정도는 맞다고 생각하지만 항상 추상화 계층을 제거하고 싶다는 의미는 아닙니다. 과거에 C를 작성하고 메모리 할당을 이해하지만 가비지 수집이 처리되는 Go로 작성하는 것을 훨씬 선호합니다. 이전의 Tensorflow 예제에 따르면 낮은 수준의 API에 작성하는 것이 더 성능이 좋지만 Python keras 추상화의 사용 편의성에 대해서도 할 말이 많습니다. 마찬가지로 Redux 대 Jumpstate(또는 이 문제에서 파생된 추상화)의 경우 상용구가 반드시 작성하기 어려운 것은 아니며 원시 Redux의 모든 유연성이 필요하지 않은 대부분의 사용 사례에서 성가신 일입니다.

그것이 나에게 달려 있다면 나는 이것을보고 싶습니다 :

• 바닐라 Redux보다 타이핑하기 쉬운 Flow/TypeScript 친화적 하위 집합입니다.
• 상수를 그다지 강조하지 않습니다(단지 문자열 리터럴을 더 안전하게 사용하도록 하십시오).
• React 또는 다른 뷰 라이브러리로부터 독립성을 유지하지만 기존 바인딩을 더 쉽게 사용할 수 있도록 합니다(예: mapStateToProps 구현 제공).
• Redux 원칙 유지(직렬화 가능한 작업, 시간 여행 및 핫 재로딩이 작동해야 하고 작업 로그가 의미가 있어야 함).
• 보다 직관적인 방법으로 코드 분할을 지원합니다.
• 리듀서와 선택기를 함께 배치하도록 장려하고 함께 작성하는 것이 덜 어색하게 만듭니다(작성 ​​및 구성이 쉬운 리듀서-선택기 번들 생각).
• 액션 생성자를 리듀서와 함께 배치하는 대신 액션 생성자를 완전히 제거하고 액션 대 리듀서의 다대다 매핑을 자연스럽게 만듭니다(대부분의 라이브러리처럼 피하는 대신).
• 합리적인 성능을 기본값으로 설정하여 사용자가 해당 코드를 작성하지 않고 일반적인 사용 사례에 대해 Reselect를 통한 메모화가 "그냥 작동"합니다.
• 인덱싱, 정규화, 컬렉션 및 낙관적 업데이트를 위한 기본 제공 도우미를 포함합니다.
• 테스트 가능한 비동기 흐름 지원이 내장되어 있습니다.

물론 핵심 외에도 공식 Redux로 브랜드화하는 것이 좋습니다.
또한, 나는 이것을 쓰지 않을 것입니다. 하지만 당신은 할 수 있습니다.

저를 위해, 몇 달 전에 redux 배울 때 문서를 읽었지만 잘 이해하지 못했습니다. 그래서 src 코드 를 읽는 데 2일을 보낸 다음 api 에 대한 모든 설명을 문서가 명확 해

그리고 나서, "상태 디자인", "리듀서 부문", "미들웨어 디자인", "비동기 솔루션"......에 대한 생각이 다음 달에 프로젝트를 개발하면서 챕터도 명확해집니다.

따라서 src 코드를 읽는 것이 redux 를 배우는 가장 적합한 단계 라고 생각하고 그 redux 의 환경을 보다 원활하게 이해하고 탐색할 수 있습니다.

기본적으로 비동기 지원.

redux-thunk, redux-saga 와 같은 다른 플러그인을 사용할 필요가 없습니다.

기본적으로 비동기 지원

그것은 사람들이 더 나은 것을 찾기 전에 0.5초 동안 그것을 보는 것입니다. 구성 요소 내에서 API를 호출한 다음 콜백/약속 해결에서 디스패치를 ​​호출하는 것을 막을 수는 없습니다. 사람들이 그것을 즉시 외부화하기를 원할 뿐입니다(저 포함). 그러나 미들웨어 없이도 async를 잘 수행할 수 있습니다.

@gaearon 의 의견은 스윕이 얼마나 광범위한지를 강조한다는 점에서 완벽합니다. 나는 그가 제안한 Redux 2.0의 정밀함과 우아함, 강력함을 전적으로 사랑하고 감사하지만, 그 개선 사항 중 거의 모든 것이 나와 관련이 없습니다!

나는 그것이 실제로 매력적이라고 ​​생각합니다.

내 자신의 Redux 추상화 라이브러리 는 거의 완전히 반대입니다. 나는 단일 감속기 동작, 원자 감속기 기능을 동작 코드 및 선택기와 번들로 묶는 것, 개체 키를 위해 문자열을 완전히 없애는 것에서 엄청난 가치를 발견했습니다. 그것은 내 자신의 90% 솔루션이며 다른 무엇보다 태도에서 CRA와 유사합니다.

흥미로운 점은 다음과 같습니다. 우리가 해결하려고 하는 문제는 무엇입니까? 여러 가지 솔루션 공간을 사용할 수 있는 많은 문제가 있습니다. Dan이 그가 설명한 대로 Redux 2.0을 구축했다면 나도 그 위에 내 자신의 추상화 라이브러리를 다시 구축할 것입니다!

@jbellsey Redux는 전역적으로 앱에 작업과 상태를 제공하는 데 탁월 하지만 정의된 범위 내에서 redux 스토어의 무한 인스턴스를 가질 수 있지만 결합할 수 있습니다. 기본적으로 이것은 라이브러리에 유용합니다. 당신이 REDUX의 내부에 대해 이야기 라이브러리를 참조하면 혜택을 누릴 수 있습니다 ...

우리는 어떤 문제를 해결하려고 합니까?

앱의 전역 상태 입니다. R eliable E sthetics D elivered U nified 전자 X tensible : 마음 :

아무도 글로벌을 원하지 않습니다. 하지만 누구에게나 하나는 필요합니다 :tm:

redux를 지금처럼 단순하게 유지하십시오. 패턴입니다. 요리 책은 항상 약 100시에 나타납니다.

@markerikson 이러한 생각을 정리하기 위해 문서/스프레드시트를 시작하는 것이 좋을까요? 이미 몇 가지 놀라운 아이디어가 있었고 48시간 밖에 지나지 않았습니다 🎉

저를 위해, 나는 사람들에게 썽크나 사가를 사용하는 것을 추천하지 않습니다. 대신 JavaScript에서 종속성 주입 기술을 배우십시오.

Redux는 일반 데이터베이스로 취급하면 더 쉬워집니다.

• Redux에게 초기 상태를 알려주고 작업(이벤트)이 애플리케이션의 상태에 어떻게 영향을 미치는지 알려줍니다. (데이터베이스 스키마 및 저장 프로시저와 같습니다.)
• 그런 다음 Redux는 이를 관리하고 리스너에게 알리고 상태를 검사하고 디버그하는 방법을 제공합니다.

저에게 있어 Redux는 저에게 전부입니다(데이터베이스가 HTTP 호출을 할 것이라고 기대하지 않을 것입니다). I/O 및 비동기 작업의 경우 Redux 외부에서 수행합니다. 이것은 Redux 스토어를 예측 가능하게 유지합니다. 유형 서명은 항상 store.dispatch(actionObject) 입니다. 디스패치 기능이 없고 작업 내부에 숨겨진 의미가 없습니다(예: 작업을 디스패치하면 API 호출이 수행되지 않음).

@tannerlinsley : 네,

이 논의를 시작하는 나에게 한 가지 단점은 : 나는 이미 내가 약에 대한 작업 및 쓰기에 필요한 물건의 톤을 가지고있다. 대부분은 자체적으로 부과되지만, 내가 조사하고 싶은 Redux 관련 주제 중 일부에 대해 작업할 시간이 충분하지 않다는 것을 의미합니다. 할퀴다.

나는 이러한 가능한 노력에 절대적으로 참여하고 싶지만 다른 사람들이 참여하고 함께 일해야 할 것입니다. (모든 OSS 관리자의 유명한 마지막 말... :))

Redux는 일반 데이터베이스로 취급하면 더 쉬워집니다.

이것이 내가 추천하는 것입니다!

• 상점을 정상화하십시오.
• 보기와 같은 데이터를 준비할 수 있습니다. 전용 감속기 로 이 작업을 수행합니다. 그러면 reselect 가 필요하지 않습니다. 고려하다.
• 작업은 다른 작업을 트리거해서는 안 됩니다. 이는 쉬워 보일 수 있습니다. 하지만 componentDidMount 후크가 있으면 어렵습니다. 이 문제를 해결하는 방법을 모르겠습니다. 이것을 계층 구조에서 위로 이동하는 것이 항상 쉬운 것은 아닙니다.

FWIW, 저는 Redux를 D3.js (React 없이)와 함께 사용해 왔으며 꽤 잘 진행되고 있습니다. 이에 대한 몇 가지 예가 d3-component 에 나열되어 있습니다.

React Redux 바인딩에서 가장 그리운 것은 connect 입니다. @gaearon 의 위 개요/비전에서 내가 가장 관심을 mapStateToProps 구현 제공"입니다.

보기와 같은 데이터를 준비할 수 있습니다. 전용 감속기로 이 작업을 수행합니다. 그러면 다시 선택할 필요가 없습니다. 고려하다.

예, 이것은 트위터가 상점에서 하는 일입니다. 적어도 제 생각에는 그렇게 생각합니다. 데이터 맵에 대한 일반 ID와 기본적으로 기본 피드인 timeline 보기를 포함하는 entities 분기가 있습니다. 엔티티 브랜치에 대한 id 참조를 보유하지만 이미 미리 계산된 것을 확인하십시오.

그리고 그것은 매우 동적인 목록을 다시 선택하는 것이 ... 너무 성능이 좋지 않기 때문에 다가오는 리팩터링에서 내가 원하는 것입니다.) 내가 볼 수있는 유일한 단점은 데이터가 중복되고 뷰에 대한 업데이트 및 삭제를 조작하는 것입니다. 약 2개소(또는 그 이상)를 자주 기억해야 하므로 장기적으로 상당히 번거롭습니다.

@stefensuhat 스스로 Redux를 구현하려고 할 때 Promise 루프를 사용하여 비동기 작업을 가능하게 했습니다. https://github.com/iddan/delux 에서 확인할 수 있습니다.

@gaearon 님 의 목록에 전적으로 동의합니다! 우리는 내가 일하고 있는 조직에서 목록의 90%를 따르는 redux 상용구를 작업하고 있습니다(또한 ducks principes를 따름). 현재로서는 출시 준비가 되지 않은 초기 릴리스입니다.

이 좋은 아이디어에 기여하고 싶습니다!

@markerikson @tannerlinsley

이러한 아이디어를 구성하는 것과 관련하여 스프레드시트를 만든 후 해당 저장소에 Github 이슈를 생성하여 개발을 추적할 것을 제안합니다. 그런 다음 해당 문제 목록과 함께 여기에 댓글을 달아야 합니다.

이것은 특정 항목이 redux와 함께 제공된다는 보장은 없지만 특정 항목에 관심이 있는 사람들에게 토론을 따르고 이를 실현하기 위해 함께 작업할 수 있는 기회를 제공합니다.

이러한 제안을 현실로 만드는 부담은 각각의 새로운 기능이나 접근 방식에 관심이 있는 우리 모두에게 있습니다. Mark가 토론을 시작했지만 아무도 그가 가서 모든 것을 구현하기를 기대하지 않을 것입니다. :)

네, @gaearon 의 목록은 이상적이지만 이미 일부 사람들이 언급했듯이 그것은 많은 것입니다. 그것을 똑바로 다루려고 하는 사람은 누구나 망각에 바이크 셰딩에 직면하게 될 것입니다. 나는 그것이 관계없이 일어나는 것을 보고 싶지만 맨 위에 전체 레이어를 구축하는 것보다 작은 조각을 한 번에 공격해야한다고 생각합니다 (다시 미리 구성된 스타터 스토어의 예를 밀어 넣습니다 ;))

즉, 누군가가 전체 목록을 공격하려고 할 때 Redux 외부, 심지어 React 외부에 존재하는 다른 도구와 프레임워크도 염두에 두십시오. React/Redux는 Vanilla Flux, MobX, VueJS 및 Angular보다 생태계에 대한 흥미로운 이점이 있습니다. 커뮤니티가 무엇을 하든, 아마도 이러한 이점 중 일부(일부는 @gaearon 목록의 일부임)에 계속 초점을 맞추고, 맨 위에 구축되는 레이어가 완전히 중복되지 않도록 하기를

내가 만들고 있는 예: 자동으로 생성된 감속기를 자동으로 업데이트하는 함수를 만들 수 있는 모듈을 만드는 것은 유혹적일 수 있습니다. 그러나 일단 그렇게 하면 MobX를 복제하므로 그다지 유용하지 않습니다.

@Phoenixmatrix 예 내 말은 redux에 기본 미들웨어가 있으므로 외부 미들웨어를 사용할 필요가 없다는 것입니다. 😄

나는 Redux의 현재 구현에 아무런 문제가 없다고 생각합니다. 상용구는 존재하지만 유형 시스템이 있는 경우에는 실제로 큰 문제가 되지 않습니다.

나에게 한 가지 중요한 문제는 사람들이 몇 년 전보다 훨씬 더 복잡한 프론트엔드 애플리케이션을 구축하고 있다는 사실을 이해하지 못하는 것 같다는 것입니다. 대규모 팀과 함께 더 크고 더 복잡한 응용 프로그램을 구축하는 경우 어려움이 크게 증가하고 새로운 패턴이 등장하지만 사람들이 그 어려움을 거부하는 것이 제게는 정상입니다.

나는 우리가 일을 더 단순하게 만들거나 상용구를 줄이려고 해서는 안 된다는 말을 하는 것이 아니라 사람들이 Redux를 사용하기 시작해서는 안 되며 상충 관계를 이해하고 큰 그림을 보지 않고 관련된 상용구에 대해 불평해서는 안 된다고 말하는 것이 아닙니다.

Redux가 만들어졌을 때 많은 사람들(저 포함)이 그것을 구축하려고 노력했고 @gaearon 은 최고의 구현을 얻었고 툴링/데모에서 아주 좋은 작업을 했습니다. 그것은 시간 여행뿐만 아니라 많은 사람들에게 새롭지 않고 즉시 자연스러워지는 개념 때문에 처음에 많은 관심을 받았습니다.

사람들은 Redux를 반짝이는 새 장난감으로 봅니다(실제로는 그렇게 쉽지 않은 것 같습니다). 그러나 누군가가 이러한 개념을 우아한 방식으로 프론트엔드에 이식했다는 사실을 제외하고 Redux에서 실제로 새로운 것은 없습니다. Redux와 그 생태계의 패턴은 이미 분산 시스템, 이벤트 소스 백엔드 애플리케이션, 도메인 주도 설계에 사용되고 있으며 이에 대한 배경 지식이 있는 사람들은 Redux를 매우 쉽게 이해할 것입니다.

불행히도 사람들은 관련된 보다 일반적인 패턴에 대해 전혀 알지 못한 채 단계를 건너뛰고 Redux를 사용하기를 원합니다. 개인적으로 저는 분산 시스템에 대한 최소한의 배경 지식을 갖추기 위해 Redux에서 진지한 것을 구축하고자 하는 사람을 추천합니다. 이상하게 보일 수 있지만 그런 종류의 배경을 가지고 있으면 현재와 앞으로 몇 년 동안 매우 중요한 이점을 얻을 수 있다고 생각합니다.

프론트엔드 애플리케이션을 구축할 때 정확히 무엇을 구축하고 있습니까?

• 우리는 분산 시스템의 구성원을 구축
• 해당 구성원은 보다 일반적인 시스템의 데이터 하위 집합만 보유합니다.
• 그 구성원은 용량이 상당히 제한되어 있습니다(스토리지, 대역폭, 네트워크 안정성...).

그래서 우리는 매우 복잡한 것을 만들려고 합니다. 우리는 데이터베이스 개발자보다 처리하기 더 어려운 제약 조건을 가지고 있지만 수년 동안 이러한 문제에 대해 정말로 열심히 생각한 사람들의 이전 지식을 재사용하지 않고 기본적으로 더 간단하기를 원합니다. 사람들이 이미 DB 내부의 상태를 구성하는 방법에 대해 생각했다고 생각하지 않습니까? 그것을 쿼리하는 방법?

나는 우리가 오늘날 응용 프로그램을 실용화하고 현재 지식으로 실수를 해서는 안 된다고 말하는 것이 아니라, 우리가 구축하고 있는 것이 더 이상 단순하지 않고 추가 지식이 필요하다는 것을 이해하고 인정해야 합니다. Redux는 이러한 지식을 얻는 좋은 방법일 수 있으며 처음에는 실용적인 방식으로 사용할 수 있지만 앞으로 몇 년 동안 프론트엔드 개발이 얼마나 당신을 불편하게 만들지 과소평가하지 마십시오.

불행히도 사람들은 관련된 보다 일반적인 패턴에 대해 전혀 알지 못한 채 단계를 건너뛰고 Redux를 사용하기를 원합니다.

좋든 나쁘든 Redux는 본질적으로 React 상태 관리 전쟁에서 승리했습니다. 이를 통해 생태계를 형성할 수 있는 능력이 생깁니다. 작동하는 무언가를 원하는 개발자는 항상 있을 것이며, 이것만 있으면 되는 더 간단한 응용 프로그램이 많이 있습니다. 사람들은 계속해서 다른 추상화 계층을 사용하거나 간단한 라이브러리를 통해 올바른 일반 패턴을 소개받을 수 있습니다.

개인적으로 저는 분산 시스템에 대한 최소한의 배경 지식을 갖추기 위해 Redux에서 진지한 것을 구축하고자 하는 사람을 추천합니다. 이상하게 보일 수 있지만 그런 종류의 배경을 가지고 있으면 현재와 앞으로 몇 년 동안 매우 중요한 이점을 얻을 수 있다고 생각합니다.

이것이 문제의 핵심입니다. Redux as is는 그것을 이해하는 사람들에게 훌륭하게 작동합니다. 그러나 그것을 단순화하는 것이 반드시 나쁜 것은 아닙니다. 일반적으로 이해하면 더 나은 코드를 작성하는 데 도움이 되지만 대부분의 사람들은 더 이상 어셈블리 코드를 작성하지 않습니다. 그것은 대부분의 사람들이 시작하는 곳이 아닙니다.

주위에 좋은 의견이 더 많습니다. 여기에는 우리가 더 탐구할 수 있고 더 탐구해야 하는 아이디어가 많이 있습니다.

잠재적으로 실행 가능한 몇 가지 아이디어를 생각해 낼 수 있는지 봅시다. 작은 기본 개념을 던져서 시작하겠습니다.

redux-starter 같은 새 패키지를 만듭니다. 해당 패키지는 redux-actions , redux-thunk 및 redux-logger , 그리고 아마도 약속 기반 미들웨어에 의존할 수 있습니다. function createReduxStore({reducers, middleware}) {} 시그니처가 있는 함수를 제공합니다( 이전 @Phoenixmatrix 의 설명을 기반으로

createReduxStore() 함수는 applyMiddleware 및 루트 리듀서에 대한 핫 리로딩 설정, Redux DevTools 확장 구성을 처리합니다. 미들웨어가 제공되지 않으면 기본적으로 포함된 미들웨어를 구성합니다. 이것은 ember-redux 의 상점 서비스 설정 코드 또는 내 "Project Mini-Mek" 샘플 앱 의 있습니다 .

이렇게 하면 시작하는 데 필요한 설정의 양을 최소한 최소화하고 적당한 수준의 유용한 기능을 제공합니다.

네, 저는 그것을 좋아합니다. (글쎄요, 새로운 사용자를 위한 redux-actions 및 promise 기반 미들웨어는 좋아하지 않지만, 나는 당신이 그것에 대해 bikeshedding을 즐기게 할 것입니다). 미들웨어 수락을 귀찮게하지 않고 createStarterStore(reducer)만 하면 됩니다.

CombineReducer를 대체할 수도 있으므로 간단히 다음을 수행할 수 있습니다.

const store = createStarterStore({
   foo,
   bar,
   baz
});

foo bar baz는 감속기입니다.

드래트. "루트 리듀서에 대한 HMR을 설정하는 라이브러리 기능"이 아마도 작동하지 않을 것이라는 것을 깨달았습니다. 왜냐하면 사용자가 루트 리듀서 파일에 대한 경로를 전달하도록 허용하더라도 module.hot.accept() API 및 require(path) 다시 가져오기 단계는 변수가 아닌 빌드 시 정적으로 분석 가능한 경로를 원합니다. (제 생각에는... 제가 틀릴 수도 있습니다.) 아, 글쎄요.

하지만 createStarterStore() 는 루트 리듀서나 슬라이스 객체를 받아들일 수 있습니다.

개인적으로 저는 분산 시스템에 대한 최소한의 배경 지식을 갖추기 위해 Redux에서 진지한 것을 구축하고자 하는 사람을 추천합니다. 이상하게 보일 수 있지만 그런 종류의 배경을 가지고 있으면 현재와 앞으로 몇 년 동안 매우 중요한 이점을 얻을 수 있다고 생각합니다.

@slorber 그 부분에 대해서는 동의합니다.

불행히도 사람들은 관련된 보다 일반적인 패턴에 대해 전혀 알지 못한 채 단계를 건너뛰고 Redux를 사용하기를 원합니다.

그러나 실제로는 그렇지 않습니다. 어떤 사람들은 Redux와 관련된 패턴에 대해 알고 있으며 이것이 바로 그들이 Redux를 사용하기로 선택한 이유입니다. 단순한(또는 최소한 더 간단한) 것을 사용하기를 원한다고 해서 반드시 사용자가 더 어려운 구현을 사용할 수 없다는 것을 의미하지는 않습니다. 시간과 노력을 절약할 뿐입니다.

내가 일하는 곳에서 우리는 Redux를 1년 동안 사용했고, 스토어에 새로운 리소스를 추가하기 위해 동일한 코드를 복사/붙여넣기(약간 수정)했습니다. 그래서 어느 시점에서 우리는 느꼈습니다. 이 중복된 상용구를 추상화하기 위해 Redux 위에 레이어를 구현해야 합니다.
제 생각에 이 아이디어는 Redux 사용을 단순화하는 것뿐만 아니라 가장 일반적인 부분에 대한 상용구를 줄이는 것입니다(같은 방식으로 react-redux 는 Redux를 React와 함께 사용할 때 상용구를 줄입니다).

매우 흥미로운 토론입니다. 초창기부터 redux 사용자로서 두 센트:

내가 기억하는 것처럼 처음에는 redux를 앱을 빌드하기 위한 프레임워크라기보다 프로토콜이나 합리적인 규칙의 집합으로 여겼습니다. 이러한 엄격함은 redux가 새로운 사람들에게 압도적이고 자신의 추상화를 롤링하지 않고 확장하는 데 지루할 수 있는 이유 중 일부입니다. 그러나 2015년에 상태 관리의 혼란을 뚫고 나온 간단한 방법은 그것이 시작된 이유이기도 합니다. 미니멀리즘 덕분에 Apollo와 같은 놀라운 프레임워크가 다른 프로젝트(특히 개발 도구)에서 수행한 작업을 편승하고 친숙한 방식을 제공할 수 있었습니다. 필요할 때 상태 관리에서 "낮은 수준으로 떨어뜨리기".

"낮은 수준" 라이브러리인 redux는 큰 성공을 거뒀고 앱을 빌드하기 위한 기능이 풍부한 프레임워크로서는 아직 충분하지 않다고 생각합니다. 주의해야 할 한 가지는 redux가 발전함에 따라 Apollo와 같은 프로젝트의 산업 표준 "프로토콜"로서의 역할을 손상시키지 않는다는 것입니다.

이를 위해 현재 redux는 redux-core 와 같은 패키지가 될 수 있으며 redux 자체가 추상화 수준을 높여 권장되는 앱 빌드 방법을 제공할 수 있습니다. 물론 redux-core를 사용하여 이 redux (Apollo 또는 saga를 사용하는 것)에 대한 더 높은 수준의 대안이 얼마든지 있을 수 있습니다.

설명과 강조를 위해 다시 언급:

이 스레드의 작업 에는 기존 Redux 라이브러리에 대한 주요 변경 사항이 포함되지 않습니다. :) 문서 수정이 완전히 가능하고 약간의 조정이 있을 수 있지만 기존 redux 패키지는 그대로 유지됩니다.

내가 방금 설명한 redux-starter 패키지 또는 Dan이 설명한 "프레임워크" 접근 방식과 같은 것은 redux 에 의존하는 새 패키지가 될 것입니다.

@markerikson이 제안한 것과 같은 패키지를 만드는 데 투표합니다. 코드베이스가 있으면 API, 코드 스니펫 및 보다 심층적인 아이디어에 대해 논의할 수 있습니다. 그런 다음 특정 기능에 대한 문제를 생성할 수 있습니다.

Delux를 스타터(jk)로 사용할 수 있습니다.

@tannerlinsley 의 Jumpstate(현재는 유지 관리 중 하나)를 많이 사용하는 사용자로서 저는 이 점에 대해 매우 기쁩니다. 내가 Jumpstate를 사용하는 이유는 @gaearon 의 원래 게시물에 매우 간략하게 설명되어 있습니다. 즉, 완전한 솔루션이 아닙니다(의도한 적이 없음). 오늘 아침에 이것 외에 추가할 수 있는 몇 가지 사항을 생각하다가 이 스레드를 발견했고 여러분이 이미 그것에 대해 생각하고 있다는 것을 알게 되었습니다.

장황한 말투: 대단해 보이네요. 제가 참여하고 있습니다. 제가 얼마만큼 기여할 수 있을지는 잘 모르겠지만(노력할 것입니다) 당신에게는 확실히 치어리더가 있습니다.

저는 Jumpstate를 사용하여 Redux를 여러 번 가르쳤으며 학습 곡선을 상당히 단축했다고 자신 있게 말할 수 있습니다. HTTP와 같은 Redux와 fetch와 같은 Jumpstate를 생각합니다. 저는 Redux를 사랑하고 Redux를 사용하여 (우스꽝스러울 정도로) 복잡한 내용을 작성했지만, 90%의 경우가 대부분의 것을 가르치기에 충분하다는 것도 압니다.

당신이 그것에 대해 생각할 때 이것은 좋은 곳입니다. 일반적으로 프론트엔드 개발 및 자바스크립트에 대한 핵심 불만 중 하나는 "표준 라이브러리의 부족"입니다. 문제는 이것은 브라우저에서 전체 애플리케이션을 개발할 수 있는 매우 새로운 것 (TM) 이라는 것입니다. 마침내 표준 라이브러리가 필요하다는 압력이 높아지고 있습니다. 그것이 우리가 지금 있는 곳입니다.

Re: 학습 곡선, 독창성 및 추상화:

Ajax는 썽크(thunk), 사가(saga) 또는 서사시(Epics)를 사용하는 방법을 배우는 새로운 학습자가 막히는 영역인 것 같습니다. 그다지 어려움이 없어 보이는 영역 중 하나는 액션을 생성하는 것입니다. 액션을 생성하는 것입니다. 액션은 그저 오래된 Javascript 객체일 뿐이고 Flux Standard Actions 사양에서 제공하는 명확성을 추가했기 때문입니다. 이러한 사고 방식은 나를 Flux Standard Ajax Action을 개발하지 않는 이유에 대한 질문으로 이끌었습니다.

예

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

ajax 작업은 미들웨어에 의해 처리됩니다(작업의 ajax 키에 반응함).

나는 이 접근 방식이 왜 나쁜 생각일지 이유를 생각하려고 노력했지만 아직 거래 차단에 대해 생각해 본 적이 없습니다.
내 추정에 몇 가지 이점:

• 평균 애플리케이션에 필요한 비동기 작업의 양이 급격히 감소합니다(Ajax 관련 비동기 작업이 떨어지기 때문에).
• 우리는 평범한 오래된 자바 스크립트 객체만을 다루기 때문에 이해하기 쉽습니다.
• 선언적이며 구현 세부 사항은 중요하지 않습니다.
• 다양한 구현을 중단 없이 교체할 수 있습니다.
• 관용적 Redux입니다(작업 로그는 여전히 의미가 있고 직렬화 가능 등).

일부 사람들이 관심 분리 주장을 주장하는 것을 들을 수 있지만, 이는 우리의 ajax 요청 작업이 이미 수행하고 있는 작업에 대한 자연스러운 확장이라고 주장하고 싶습니다. 현재 그들은 'FETCH_POSTS_REQUEST' 라는 매우 명확한 컨텍스트로 작업을 설정하고 있지만 컨텍스트가 너무 적어서 ajax 요청 구현을 추상화합니다. 다른 곳에서 수동으로 ajax 요청을 수행하는 것 외에는 선택의 여지가 거의 없습니다.

마음에 오는 또 다른 것은 일부 문서에서 본 비동기 작업 연결입니다. 우리는 이런 방식으로 요청을 연결할 필요가 없었기 때문에 이 연결이 얼마나 널리 사용되었는지는 잘 모르겠습니다. 하지만 내 직감은 이것이 내가 제안하는 범위를 벗어날 것이라는 것입니다. 이 토론에서 언급된 90% 사용 사례에 속하지 않음).

결론적으로 - 이와 같은 추상화는 일반적인 Redux 응용 프로그램을 작성하는 데 필요한 학습 곡선과 코드의 양을 줄이는 데 도움이 될 것 같습니다. 이 접근 방식에 대해 생각하는 사람이 있습니까? 생각할 수 있는 거래 차단기가 있습니까? @markerikson @gaearon

선행 기술: redux-axios-middleware

이 스레드에서 많은 일들이 일어나고 있습니다.

Redux 복잡성에 대한 논의에 대해. 개인적으로 나는 사람들이 Redux가 복잡하고 장황하다는 불평에 동의하지 않습니다. Flux 및 Elm 아키텍처를 기반으로 하는 저수준 라이브러리를 사용할 때 트레이드 오프가 발생합니다. Redux 홈 페이지 에 필요하지 않을 수

Redux는 있는 그대로 찾습니다. 운이 좋게도 핵심 팀은 기능이 완벽하다는 것을 알고 있으며 변경할 의사가 없습니다. 그 위에 구축된 추상화는 훌륭하고 각각 고유한 사용 사례가 있습니다. 이것은 훌륭하고 잘 설계된 저수준 라이브러리에 대해 기대할 수 있는 것입니다.

나는 Redux 자체에 문제가 있는 것이 아니라 그것을 학습하는 점진적이고 즉시 사용 가능한 방법의 부족에 문제가 있다고 봅니다. 일부 언급했듯이 React 자체에도 동일한 문제가 있었고 create-react-app 가 해결책이었습니다.

아마도 그것에 대한 멋진 리소스가 있기 때문에 문제가 되지 않을 수도 있습니다(예: Dan의 egghead 시리즈 ). 학습 곡선 없이 복잡한 문제를 해결하는 라이브러리를 사용하려는 사람들이 문제일 수 있습니다.

어쨌든, 이것은 이 스레드에 관한 것이 아닙니다.

@markerikson 저는 개인적으로 이 redux-starter 개발에 도움을 드리고 있습니다.

_저는 더 멋진 이름을 원합니다_ :stuck_out_tongue:

많은 작업을 생성하는 데 필요한 상용구는 거의 redux에서 볼 수 있는 유일한 단점입니다.

매우 낮은 수준이지만 훌륭하다고 생각합니다. 그것이 내가 MobX보다 Redux 스타일 패러다임을 선호하는 이유 중 하나지만, 예를 들어 유용성을 이해하고 MobX를 사용할 것입니다. 하지만 Redux를 이해하게 된 지금은 그렇게 하는 것만으로도 행복할 것입니다. Redux(또는 일반적으로 Redux 패턴) 때문에 데이터는 특히 "뒤에서" 진행되지 않습니다. 일반적으로 코드가 처리되는 곳마다 작성하고 그렇지 않은 경우 이해할 수 있습니다(시간을 들여 학습한 경우 나중에 자세히 설명).

문제는 제가 Redux를 처음 배울 때 이해하기 힘든 부분이 많았지만 간단했습니다. 어려운 일도 간단할 수도 있습니다. 하지만 그렇기 때문에 "와, 이 컨셉이 너무 논리적이다! 내가 직접 할 수 있을 것 같다는 생각이 든다!" 그래서 내 첫 번째 프로젝트에서는 Redux 패키지를 사용하는 대신 나만의 작은 Redux 저장소를 만들었습니다.

그렇게 하면 Redux의 개념을 이해하는 데 도움이 되었을 뿐만 아니라 Javascript 자체에 대한 이해도 많이 높아졌습니다! (이것은 이전에 함수형 프로그래밍 개념에 대해 거의 아무것도 몰랐던 사람의 관점에서 본 것이므로 마일리지가 다를 수 있습니다.) Redux의 개념은 단순함과 동시에 믿을 수 없을 정도로 강력하다는 면에서 정말 훌륭합니다.

문제는 Redux가 매우 인기가 있기 때문에 "유행"이 새 사용자가 Javascript에서 얼마나 잘 작동하는지에 대해 주의를 분산시킬 수 있다는 것입니다. 따라서 그들의 사고 방식은 "좋아요, React, Redux 등을 얻었습니다. 이제 멋진 프로그래머가 되어 멋진 앱을 만들겠습니다!"라고 생각할 수 있습니다. 문제가 있는 것은 아닙니다. 그러나 그들은 도구가 작동하는 이유를 이해하지 못한 채 개발 프로세스를 가속화하기 위해 반짝이는 새 도구를 사용하려는 데에만 집중할 수 있습니다.

개념이 이해되면 Redux(또는 Redux와 유사한 패턴)가 모든 방식의 작업을 수행하도록 하는 것이 매우 쉬워집니다. 나는 Angular와 같은 다른 (여전히 훌륭한) 도구보다 React를 좋아하는 것과 같은 이유로 그것을 좋아합니다. _그냥 자바스크립트입니다._ 자바스크립트는 이렇게 작동합니다!
어떤 패러다임을 통해 필요한 상용구를 줄일 수 있다면 좋겠지만, Unlimiteddd powaaaaaa에 대해 지불하기에는 작은 대가라고 생각합니다.

IMO는 이 모든 "장황함은 절충안"일 뿐입니다. 상세도 아무것도의 서비스가 아닌, 당신이 전혀 돌아 오는을 사용할 수 있도록 희생입니다. 나는 Redux나 자바스크립트를 비난하는 것이 아니라 이것이 본질적인 복잡성이 아니라는 점을 지적하고 싶다. Elm은 Redux가 달성하는 모든 것을 더 적은 수의 라인과 더 간단한 코드로 관리합니다.

그래서 우리는 기계적으로 상용구를 작성합니다. Jumpstate 등은 삶을 더 쉽게 만들어주지만 런타임에 할 수 있는 일에는 한계가 있으며 typescript/flow를 사용하면 jumpstate가 별로 도움이 되지 않습니다. 그러나 codegen은 어렵고 이미 과부하가 걸린 빌드 시스템에 한 가지를 더 추가하고 싶어하는 사람은 아무도 없습니다.

관용적인 Redux로 번역된 Elm 코드와 같은 것을 가질 수 있다면... 여전히 제 심장을 뛰게 하십시오.

다음은 내 아이디어 중 일부입니다. 이전 의견을 반복하지 않기를 바랍니다.

액션 생성자를 액션 유형으로 사용할 수 있습니다.

액션.js

export function increase() {}

감속기.js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

함수에는 고유한 참조가 있으므로 이를 작업의 식별자로 취급할 수 있습니다. FSA와 호환되지 않지만 많은 코드를 저장하고 실수를 방지합니다.

작업을 비동기적으로 전달할 수 있습니다.

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

그렇게 하면 액션 생성자가 비동기 함수가 될 수 있지만 차례로 디스패치할 수 있습니다. 많은 상황에서 볼 수 있듯이 사람들은 미들웨어 기반 솔루션을 사용할 필요가 없으며 많은 상용구 코드를 절약할 수 있습니다.
이 개념은 Delux 의 Promise Factory에서 구현됩니다.

redux === 상용구

https://github.com/Emilios1995/redux-create-module

하지만 이 기능이 당신의 생명을 완전히 구할 수 있다고 생각합니다.

이 스레드에서 진행 중인 두 가지 다른 아이디어 세트를 구별할 가치가 있습니다.

• "전체 서비스" redux 기반 프레임워크
• redux 코어의 추가 기능

나는 redux 코어가 그 자체로 프레임워크가 되어서는 안 된다는 하려는지 이해합니다. 그러나 redux 코어에는 새로운 "도우미 기능"에 대한 여지와 선례가 있다고 생각합니다.

Redux는 createStore , applyMiddleware , combineReducers , bindActionCreators , compose 와 같이 상당히 작은 API 노출 영역을 가지고 있습니다. 그러나 이들 대부분은 편의 기능입니다. Redux가 작동하려면 createStore 있으면 됩니다. 왜 이들 중 하나가 핵심에 속합니까?

• applyMiddleware 는 인핸서를 저장하기 위한 단순화된 인터페이스를 만듭니다. 그러나 더 중요한 것은 applyMiddleware 이 미들웨어 _interface_를 redux 스토어에 효과를 추가하는 표준 방식으로 지원한다는 것입니다. 미들웨어 생태계가 가능한 이유는 applyMiddleware 인터페이스가 비교적 단순하고 사용자가 여러 미들웨어를 동시에 실행할 수 있기 때문입니다.

• combineReducers 는 편리한 감속기 구성을 제공합니다. 감속기를 구성하는 유일한 방법은 아니지만 확실히 더 유용한 패턴 중 하나입니다. 그러나 redux 코어에 존재한다는 것은 그것이 일반적일 뿐만 아니라 _유비쿼터스_하다는 것을 의미합니다. 내가 만난 모든 중요하지 않은 Redux 앱은 combineReducers 를 사용하여 루트 감속기를 만듭니다. 이것의 이면은 combineReducers 가 Redux와 함께 제공되는 유일한 형태의 감속기 구성이기 때문에 많은 사용자가 그것이 존재하는 유일한 형태의 감속기 구성이라고 믿는 것 같습니다.

• bindActionCreators 는 디스패치 작업과 관련된 일부 상용구를 줄입니다. 그러나 반대로 bindActionCreators 는 또한 상용구에 대한 Redux의 평판에 간접적인 책임이 있습니다. bindActionCreators 존재만으로도 액션 크리에이터의 활용을 독려하기 때문이다. 이것은 액션 생성자( bindActionCreators "보증")와 선택자(문서화되었지만 동등한 핵심 기능이 없음)의 보급률을 비교할 때 특히 두드러집니다. mapStateToProps 는 항상 "맞춤형" 선택기이지만 mapDispatchToProps 는 항상 미리 작성된 작업 작성자의 개체 맵인 react-redux 사용하는 많은 코드베이스를 보았습니다.

이들 중 어느 것도 Redux의 기능에 필수적인 것은 아니지만 모두 사용성에 필수적입니다. 이러한 함수 중 어느 것도 Redux의 고유한 유연성을 제한하지 않지만 공통 패턴을 호출 가능한 함수로 구체화하여 선택을 덜 어렵게 만듭니다. 그리고 이러한 각 도우미 함수는 추가 질문을 제기합니다.

• 미들웨어가 스토어 인핸서의 단순화라면 널리 유용할 수 있는 다른 단순화가 있습니까?
• 단순히 문서화하는 대신 어떤 다른 형태의 감속기 구성을 구현할 수 있습니까? 감속기 개체 ? 종속 감속기 ? 선형 구성 ?
• reselect를 통합하면 사람들이 이전에 없었던 선택기를 만들고 구성하게 될까요? 이것이 순 긍정적입니까?

이 모든 것에 대한 대답이 부정적일지라도, 나는 우리가 그들의 전제를 고려조차 하지 않음으로써 우리 자신과 지역 사회에 해가 된다고 생각합니다.

@modernserf : 먼저 Redux에 대한 귀하의 의견과 최근 생각에 감사드립니다. 그것들은 모두 _매우_ 가치 있고 유익하며, 아마도 이 스레드의 다른 누구에게나 필독서여야 할 것입니다. 그래서 여기에 링크하겠습니다.

• 메인 포스트: Redux의 장점은 무엇입니까?
• 게시물로 이어진 Twitter 스레드의 저장 버전: https://storify.com/acemarke/redux-pros-cons-and-limitations
• 이후 몇 가지 추가 생각: https://twitter.com/modernserf/status/886426115874717697

관련된 역사 때문에 당신이 그것들을 가져와야 한다는 것은 매우 흥미롭습니다(저는 Redux의 Tao, Part 1 - Implementation and Intent . 특히 redux-thunk 내 게시물을 위해 조사하는 데 많은 시간을 보냈습니다. react-redux 도 나중에 분리되었습니다 .

이러한 유틸리티가 실제로 특정 사용 패턴을 코드화하는 것이 맞습니다. 즉, 이러한 유틸리티는 슬라이스 감소기의 구성, 비동기 동작 및 기타 중앙 집중식 동작을 위한 미들웨어 파이프라인, 구성 요소(특히 주변에 함수 전달 자식 구성 요소에). 다소 유사하게, Reselect가 핵심은 아니지만 Dan은 명시적으로 생성을 권장했습니다 .

예, 누구나 "할 수" 있었지만 이를 구축함으로써 사람들이 특정 도구를 특정 방식으로 사용하도록 했습니다. 그것에 대해 확실히 동의합니다.

마지막 세 가지 질문에 대해:

• 당신은 미들웨어가 "스토어 인핸서의 단순화"라고 말할 수 있을 것입니다. 비록 그것이 정당하다고 생각하지는 않지만요. 오히려, 그것은 매우 특별한 목적을 위한 상점 강화제입니다. 다른 스토어 인핸서 관련 작업: Dan은 그가 여전히 수정하고 싶은 Redux 코어의 주요 부분 중 하나는 인핸서가 초기화되는 방식과 관련이 있다고 말했습니다. 실제로 매우 오랫동안 열려 있는 스토어 인핸서 구현을 변경하기 위해 "경쟁하는" PR이 두 개 있습니다. @acdlite 의 버전은 #1706이고 @jimbolla 의 버전은 #2214입니다. Jim이 커뮤니티에서 실제로 사용하는 방법을 분석하는 데 도움이 되도록 알려진 모든 스토어 인핸서 목록을 작성 했다는 점도 흥미롭습니다. 나는 Jim의 제안이 인핸서 작성자가 일반적으로 볼 수 있는 행동을 단순화하는 것을 돕기 위한 것임을 알고 있습니다. 그래서 더 탐색할 수 있는 방향이다.
• 감속기 구성 및 구조에 대한 다른 패턴이 많이 있습니다. "의존적" 리듀서만큼 우리가 할 수 있는 일은 정확히 무엇인지 잘 모르겠습니다. 왜냐하면 그것이 훨씬 더 틈새 사용 사례이고 앱에 특정한 것처럼 보이기 때문입니다. 관련 참고로, Dan은 오랫동안 combineReducers 일종의 세 번째 인수를 추가하자는 PR을 닫았지만(그리고 그 중 _많은_이 있음) 마침내 #1768이 앞으로 나아갈 수 있도록 허용했습니다. 동안. 그 PR도 중단되었습니다.
• 선택기의 가장 일반적인 사용 사례는 상태 비트를 직접 추출하여 명명된 소품으로 전달하는 것 같습니다. 우리는 또한 mapState 대한 객체 속기 구문 을 createStructuredSelector 동일한 작업을 수행할 수 있음에도 불구하고 이에 대한 많은 요청을 받았습니다.

"Redux의 Tao" 게시물에서 문서화한 것처럼 명시된 목표는 Redux 핵심 API를 가능한 한 최소화 하고 그 위에 생태계를 장려하는 것이었습니다 . 또한, Redux 개발 초기에 Andrew 는 특정 플러그인을 "축복"하려는 의도에 대해 다음과 같이 언급했습니다 .

gaearon이 한 번 말했듯이(어디가... 아마도 Slack인지 기억이 나지 않습니다) 우리는 Flux 라이브러리의 Koa처럼 되는 것을 목표로 합니다. 결국 커뮤니티가 더 성숙해지면 reduxjs GitHub 조직에서 "축복받은" 플러그인 및 확장 모음을 유지 관리할 계획입니다.

이전에 up-thread에서 나는 일종의 "쉬운 Redux 설정" 추상화 라이브러리 또는 이와 유사한 것을 제안했습니다. 그런 것 또는 적어도 "축복받은" 애드온 목록이 당신이 생각하는 라인에 따라 충분할까요? (실제로 이 스레드의 첫 번째 댓글에서도 그렇게 하셨습니다.) 그렇지 않다면 추가 제안이나 아이디어가 있습니까?

결국 커뮤니티가 더 성숙해지면 reduxjs GitHub 조직에서 "축복받은" 플러그인 및 확장 모음을 유지 관리할 계획입니다.

이것은 내가 할 일이지만 아마도 한 걸음 더 나아갈 것입니다. 현재 redux 패키지가 @redux/core 와 같은 것이 되는 단일 저장소로 프로젝트를 재구성할 것입니다. reselect 및 redux-action과 같은 라이브러리는 repo 및 네임스페이스로 가져오고 redux 패키지 자체는 이러한 모든 패키지를 단일 네임스페이스로 다시 내보냅니다.

_sort of_는 redux 코어를 수정하지 않는다는 제약 조건을 충족합니다. 또한 확장 버전은 코어의 엄격한 상위 집합이므로 하위 호환이 가능합니다. 새로운 기능은 순전히 옵트인이며 비공개 상태에 대한 특별한 액세스 권한이 없습니다. "팽창"에 관한 한 -- 이러한 각 라이브러리는 처음에는 작으며 트리를 흔드는 것이 쉽지 않은 방식으로 작성되었습니다.

또한 MapState에 대한 객체 단축 구문을 추가하기 위해 React-Redux에 대한 공개 PR이 있으며 Reselect의 createStructuredSelector 동일한 작업을 수행할 수 있음에도 불구하고 이에 대한 많은 요청이 있었습니다.

나는 이것이 당신에게 무언가를 말해야한다고 생각합니다.

제가 제안하는 monorepo 구조는 기본적으로 Lodash에서 사용하는 구조입니다. 자 -- Lodash는 본보기로 삼기에 흥미로운 라이브러리입니다. 엄청난 함수 모음이 있으며, 그 중 많은 부분이 스스로 구현하기가 쉽지 않습니다. lodash의 거의 모든 기능은 "레시피"로 더 유연할 수 있습니다. groupBy 는 결국 _패턴_입니다. 당신이 그것을 사용하는 데이터 구조를 말하는 것은 누구입니까?

그리고 모든 lodash 함수는 자체 _a la carte_ 라이브러리에서도 사용할 수 있습니다. import { groupBy } from "lodash" 보다 import groupBy from "group-by" import { groupBy } from "lodash" 에 대한 _기능적_ 이점은 없습니다. 필요한 것만 설치할 수 있는데 왜 나무 떨림을 처리해야 합니까?

그러나 Lodash를 사용하는 경험은 레시피나 나노 라이브러리를 사용하는 것과 근본적으로 다릅니다. 배열로 무언가를 하고 있고 자신을 반복하는 것 같은 느낌이 든다면 아마도 Lodash 함수가 이를 수행할 것입니다. 레시피를 찾을 필요도 없고, 아무것도 설치할 필요도 없습니다. 파일에 다른 가져오기 라인을 추가할 필요도 없을 것입니다. 아주 작은 마찰도 제거하지만 우리의 하루는 이런 순간들로 가득 차서 쌓입니다.

다른 관점에서 내 자신의 2센트를 추가하는 것에 신경 쓰지 않기를 바랍니다.

CQRS , 이벤트 소싱 , 그리고 궁극적으로 생각하는 도메인 주도 디자인 학교는 우리에게 Flux 와 Redux 를 낳은 위대한 조상입니다. 이러한 영향이 가끔 인용 되지만 Redux 와 그 후손 도구는 대부분의 API 용어를 당시 유행했던 Flux 및 Flux 구현에서 가져왔습니다. 이것은 괜찮지만 기존 노출 개발자가 이러한 아이디어에 대해 가질 수 있었던 수익을 얻을 수 있는 기회를 놓치고 있다고 생각합니다.

차이점에 대한 두 가지 예를 들면 다음과 같습니다. 내가 본 대부분의 이벤트 소싱 토론에서 Redux Actions 는 Events 라고 합니다. Redux ActionCreators 는 Commands 라고 합니다. 이 용어와 함께 무료로 제공되는 추가 명확성과 의미가 있다고 생각합니다. 이벤트 는 기록 가능하고 직렬화 가능한 데이터입니다. 사건 은 과거 시제에서 일어난 일을 설명합니다. 이벤트 를 재생할 수 있습니다. 이벤트 는 녹음을 취소할 수 없습니다. 명령 에는 명령적인 분위기가 있습니다. 명령은 이벤트를 트리거합니다.

나는 아키텍처 패턴으로서 Event Sourcing 이 향후 10년 동안 인기를 얻을 것이라고 생각하며, Redux 는 API 및 토론을 더 넓은 커뮤니티와 더 밀접하게 조정함으로써 약간의 유용성, 명확성 및 사용 용이성을 얻을 수 있다고 생각합니다.

나는 이 토론이 이미 죽도록 두들겨 맞았다고 생각합니다: https://github.com/reactjs/redux/issues/351

앗 몰랐네요 감사합니다! :+1:

당시에 취할 수 있는 조치가 없었기 때문에 #351이 폐쇄된 것 같습니다. 우리가 API 결정과 우리가 사용하는 언어를 재고하는 시점에 있다면 지금이 아이디어를 다시 표면화하기에 적절한 시기인 것 같습니다.

더 구체적으로 말할 수 있습니다.

다음은 Event Sourcing 관용구에서 영감을 받은 API가 어떻게 생겼는지에 대한 제 생각입니다.

개념

• 관찰 가능한 이벤트 스트림
• Event Stream에는 지원되는 이벤트의 유형이 잘 지정된 세트가 있습니다.
• 이벤트 스트림에 명령 디스패치
• 하나 이상의 클라이언트가 이벤트 스트림을 사용합니다.

API

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

@ajhyndman : 나는 제안과 토론에 감사하지만, 그 자전거 보관소는 완전히 칠해져 있고 말이 헛간을 떠났습니다(은유를 완전히 혼합하기 위해). Dan은 CQRS/ES 용어가 아닌 Flux 용어를 사용하기로 결정했으며 핵심 API 또는 Redux 개념에 사용되는 용어를 변경할 계획은 없습니다.

(또한, 이를 입증할 통계는 없지만 적어도 JS 커뮤니티 내에서는 CQRS/ES 용어보다 Redux의 "액션" 및 "액션 작성자" 사용에 익숙한 사람들이 더 많을 것이라고 생각합니다. )

나는 확실히 이 대화가 전에 있었다는 인상을 받았고, 그것을 다시 열지 않으려는 강한 열망이 있습니다. 😄 여기서 너무 세게 누르지는 않겠습니다. (더 나은 접점이 있다면 다른 곳에서 이 대화를 읽거나 계속하고 싶습니다.)

물론, 확고한 요소가 있고 전체 API 표면과 용어를 변경하는 것은 현 시점에서 비용이 많이 든다는 것도 맞습니다.

나는 여전히 Event Sourcing 과 Redux 커뮤니티가 서로에게서 배울 기회가 있다고 주장합니다.

• 학습 및 사용 프로세스를 단순화하지만 실제로 Redux를 숨기지 않고(그리고 "기본" Redux로의 마이그레이션/학습 경로를 제공할 수 있는) 가능한 추상화를 만들 수 있습니까?

용어를 차용하거나 API를 변경하지 않아도 우리가 찾을 수 있는 승리가 있다고 생각합니다. 예를 들어, 저장소를 "currentState가 추가 전용 목록(또는 스트림)의 "순수한 기능"(이것은 파생되거나 축소 된)인 상태 컨테이너로 설명하여 사람들을 Redux 에 소개하는 데 성공했습니다. 행동".

미래를 내다보면 redux와 같은 서버 인프라를 구현하고 추상화하는 것이 완전히 가능하다고 생각합니다( Apache Samza 및 LinkedIn 엔지니어링 팀의 다른 작업 참조). 우리가 그것을 열망한다면 클라이언트와 서버 상태 관리를 위해 유사한 추상화를 사용하는 것도 가능해야 합니다! 우리가 그것을 달성할 수 있다면 왜 동형의 영구 Redux 저장소가 아닌가?

JavaScript와 인프라 커뮤니티가 함께 결합할 수 있거나 쉽게 매핑할 수 있는 모든 개념은 이러한 기회가 더 빨리 명확해지고 추상화가 더 많이 표현될 것으로 기대합니다.

저는 이러한 아이디어 중 일부에 대해 약간 흥분하고 있는 것 같아요! 덤프라는 단어를 용서해 주시기 바랍니다.

참고: 위에서 제안한 표면을 구현하는 이벤트 스트림과 같은 Redux용 래퍼 API를 만드는 것이 가능한 것 같습니다!

https://github.com/ajhyndman/redux-event-stream

@ajhyndman 나는 래퍼가 당신의 아이디어와 함께 가는 올바른 방법이라고 생각합니다 👍

당신이 언급한 samza 및 링크드인 엔지니어링 작업과 관련하여 다른 사람들이 멋진 강연을 읽지 않았거나 시청하지 않았다면 Apache Samza 로

그 비디오는 굉장하다! redux repo의 README에 있는 감사 목록의 두 번째 항목이기도 합니다.

안녕 모두들!

이 스레드의 존재를 인식하지 못한 채 나는 @markerikson 의 원래 질문에 대한 직접적인 답변이고 @gaearon 의 목록 에서 대부분의 것을 제거하는 라이브러리를 개발했습니다.

라이브러리 이름은 Kea입니다 .

redux, redux-saga 및 reselect에 대한 추상화입니다. 그것들을 함께 연결하는 접착제를 제외하고 Kea는 새로운 것을 생성하는 척하지 않으며 필요에 따라 원시 redux 액션 생성기 및 감속기, 원시 redux-saga 사가 및 원시 재선택 선택기를 노출 합니다. 새로운 개념을 발명하지 않습니다.

Kea는 다양한 작동 모드를 지원합니다. 독립 실행형으로 사용할 수 있고, React 구성 요소에 연결하거나, React 구성 요소 위에 인라인 처리하거나, 선택기에 대한 입력이 React 구성 요소의 props에 의존하는 React 구성 요소에 동적으로 연결할 수도 있습니다.

저는 개인적으로 두 개의 큰 응용 프로그램과 함께 사용합니다. 하나 는 개인 레슨용 마켓플레이스 이고 하나는 하나의 거대한 차량 추적 소프트웨어입니다. 게다가 나는 그것으로 자신의 앱을 만든 사람들을 알고 있습니다. 그것은 우리에게 매우 유용했기 때문에 그것을 정리하고 문서를 작성하는 데 상당한 시간을 보냈습니다.

저에게 이 라이브러리는 redux 자체의 핵심에 충실하면서 항상 상용구를 크게 줄였습니다.

어쨌든 충분한 이야기가 있습니다. 여기에 몇 가지 코드가 있습니다. 이것은 내가 "인라인 케아(inline kea)"라고 부르는 것의 한 예입니다. 여기서 로직이 컴포넌트에 직접 연결됩니다. 이 모드는 막 시작하거나 React의 setState 있습니다.

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

앱이 성장하고 더 많은 장소에서 increment 및 decrement 작업 또는 counter 소품에 액세스해야 하는 경우 다음과 같이 코드를 분할할 수 있습니다.

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

그것을 시도 하고 문서 를 읽고 redux-saga를 통한 부작용 및 사용할 수 있는 기타 기능에 대해 자세히 알아보세요.

Kea에 대한 피드백은 "더 많은 사람들이 Redux 세계를 더 나은 곳으로 만들기 위해 KeaJS를 사용해야 합니다! 👍" 라는 문제를 인용하여 지금까지 압도적으로 긍정적이었습니다.

시간을 내주시고 여기까지 읽어주셔서 감사합니다! :)

좋아 보인다! 'increment' 마법의 끈이 정말 마음에 들지 않습니다.

이 토론이 다른 곳으로 진행되었습니까? Kea는 일반적으로 인정되는 가장 정확한 결과입니까?

@lucfranken : 아니요, 토론이

Redux보다 높은 수준의 추상화를 찾고 있다면 Kea가 아마도 좋은 선택일 것입니다. 스토어 설정 프로세스를 간소화하는 "Redux 스타터 팩"을 찾고 있다면 몇 가지를 살펴봐야 할 수도 있습니다. 나는 야생에서 그런 것을 본 적이 있다는 것을 알고 있지만, 우리는 지금 그런 공식적인 라이브러리가 없습니다.

여기 링에 내 모자를 던졌습니다. 이것이 내가 이 문제를 해결하는 방법입니다: https://github.com/HenrikJoreteg/redux-bundler

저는 개인적으로 이것이 상용구의 큰 단순화와 감소라고 생각합니다.

내가 최근에 만든 모든 것을 그렇게 짓고 있습니다.

도움이 될 것 같아요 :
https://github.com/anish000kumar/redux-box

안녕하세요, 저희 회사에서는 네트워크 계층을 관리하고 Redux에서 많은 상용구를 제거하는 라이브러리를 오픈 소스로 제공했습니다. 우리에게 성공적인 것으로 입증되었지만 직접 사용해보십시오: https://github.com/Brigad/redux-rest-easy/ (중간 기사: https://engineering.brigad.co/introducing-redux-rest-easy -6e9a91af4f59)

redux 상용구를 줄이는 방법은 다음과 같습니다.

https://github.com/zhDmitry/restate

스레드의 매우 뒤늦은 괴사로, 얼마 전에 나는 "보일러 플레이트"가 사람들에게 의미하는 바에 대해 Twitter에서 피드백을 요청했습니다.

https://twitter.com/acemarke/status/969040835508604929

네크로 스레드의 귀환!

이 스레드의 첫 번째 주석을 편집한 결과 여기에서 논의된 아이디어가 Redux-Starter-Kit 패키지 로 바뀌었습니다. 사용해 보고 Redux 사용을 단순화하는 데 얼마나 도움이 되는지 확인하세요!