Redux: 모든 상태를 하나의 불변 원자에 저장하는 단점은 무엇입니까?

좋은 질문입니다. 내일 포괄적 인 답변을 작성하려고 노력하지만 먼저 일부 사용자의 의견을 듣고 싶습니다. 나중에이 토론을 공식 문서 페이지로 요약하면 좋을 것입니다. 우리는 단점을 몰랐기 때문에 처음에는 이것을하지 않았습니다.

대단히 감사합니다! 나는 이것에 대해 정말로 듣고 싶었다.

그건 그렇고,이 토론에 기여하고 싶은 모든 사람들이 Redux로 무엇을 구축했는지에 대한 아이디어를 제공하여 프로젝트의 범위를 더 쉽게 이해하도록 권장합니다.

OM 및 redux 및 기타 단일 상태 원자 라이브러리와 같은 어려운 질문 b / c 프로젝트는 단점을 적극적으로 완화합니다. 불변성 제약이없고 제어 된 액세스 제어가 단일 상태 원자에 대한 모든 데이터를 window 첨부하는 것과 전혀 다르지 않습니다 (그 단점은 잘 알려져 있음).

Redux 접근 방식과 관련하여 우리에게 가장 큰 단점은 단일 상태 원자가 일종의 전부 또는 아무것도 없다는 것입니다. 쉬운 수분 공급, 스냅 샷, 시간 여행 등의 이점은 중요한 국가 생활이 _no_있을 때만 효과가 있습니다. React의 맥락에서 이것은 Store의 구성 요소에 적절하게 속하는 상태를 저장해야 함을 의미합니다. 모든 것을 Redux에 넣고 싶다면 종종 부담스럽고 ​​장황하게 끝나고 성가신 수준의 간접적 인 수준을 추가합니다.

그러나 이러한 단점 중 어느 것도 우리에게 특별히 금지되지 않았습니다. :)

그래서 저는 게임 상태를 모델링하기 위해 Redux와 이러한 스타일의 아키텍처에 주목했습니다. 저는 Civ 스타일의 시뮬레이션 된 세계를 만들고 완전히 기록 된 보드 게임 기록을 브라우저 컨텍스트에서보다 간단하게 만드는 데 관심이 있습니다. 이는 아마도 일부 사람들에게는 이례적인 사용 사례 일 것입니다.하지만 누구도 제가 그만두기를 원할 것 같지는 않습니다.

그런 맥락에서 저는 히스토리 데이터 구조의 크기를 관리하고, 일부를 서버 나 디스크로 이동하여 저장하고, 특정 세그먼트를 복원하는 등의 노력에 관심이 있습니다.

내가 고생 한 것은 새로운 사용자로서 Redux의 극단적 인 (imho) 코딩 스타일 변화와 동시에 개념적 변화를 극복하려는 것입니다. 한 달이 지난 지금도 조금 벅차고 깊이 들어 가려고 시도한 후 변경됩니다. 개념을 이해하기 위해 https://github.com/ngrx/store를 살펴보고 있지만 더 친숙한 스타일 / 구문과 나머지 프레임 워크가 암시 / 제공된 더 많이 있습니다.

나는 어떤 사람들에게는 프레임 워크가 버팀목이라는 것을 이해합니다. 그러나 우리 중 일부는 그것들이 필요합니다. 유용한 강력한 의견을 가질 수있을만큼 게임의 최상위에있는 사람은 거의 없을 것입니다. 따라서 프레임 워크는 어둠 속에서 더듬 거리는 것보다 낫습니다. 그래서 그것은 개념에 새로운 중간 수준의 중년 프로그래머 나에게서 포인트입니다 :)

기본적으로 Redux와 귀하의 비디오는 원시 자바 스크립트로 수행하는 방법을 가르쳐 주었지만 경험이 적은 프로그래머이기 때문에 추가 지침없이 제품을 제공하는 방법을 알지 못하므로 완성 된 예를 볼 때까지 그냥 다음과 같이 서 있습니다.

당신의 잘못은 아니지만 여전히 해결을 돕고 싶은 문제입니다. :)

이 시점에서 여전히 가장 큰 질문은 함수, 인스턴스 또는 약속과 같은 직렬화 할 수없는 항목이 어디로 가야 하는가하는 것입니다. 지난밤 Reactiflux에서 이것에 대해 궁금해했고 좋은 반응을 얻지 못했습니다. 또한 누군가가 http://stackoverflow.com/questions/35325195/should-i-store-function-references-in-redux-store 게시하는 것을 보았습니다.

여러 상점에 대한 사용 사례 (내가 생각할 수있는 가장 좋은 점을 명심하십시오) :

여러 하위 앱을 함께 결합하는 앱입니다. My Yahoo 또는 다른 사용자 정의 가능한 홈 페이지 제품과 같은 것을 생각해보십시오. 각 위젯은 둘 사이에 겹치지 않고 자체 상태를 유지해야합니다. 제품 팀은 각 위젯에 할당 될 가능성이 높으므로 다른 사람의 코드가 환경에 미치는 영향을 모를 수 있습니다.

모이면 Redux에서 몇 가지 규칙을 위반하고 React의 컨텍스트와 같은 항목에 해당 저장소를 전파하는 데주의함으로써이를 달성 할 수 있습니다. 그러나 기본적으로 여러 상태 원자를 처리하는 프레임 워크를 사용하면 더 쉬울 수 있습니다.

@gaearon 우리는 거래 플랫폼을 구축하고 있습니다. 나는 이미 한 상점이 우리에게 적합하지 않은 이유를 한 번 설명했습니다 (상트 페테르부르크에서 React.js 밋업 이후). 자세한 내용을 다시 설명하겠습니다 (미디엄 블로그 게시물에서?).하지만 제 영어 실력 때문에 도움이 필요할 것입니다. :) 트위터에서 직접 검토하기 위해 여기에있는 다른 사람이나 귀하에게 보내도 괜찮습니까? 완료 될 때 메시지? 정확한 날짜를 정할 수는 없지만 조만간이 게시물을 작성하려고합니다 (이번 달 말일 가능성이 가장 높음).

그리고 예, @timdorr가 말한 것처럼 문서의 일부 규칙을 위반하여 여러 상점에서 Redux를 사용하고 있습니다 (그 비용으로 다양한 상점의 데이터가 필요한 경우 react-redux 를 편안하게 사용할 수 없습니다. 단일 매장의 경우)

Redux는 기본적으로 소비 할 단일 프로젝션이있는 이벤트 소싱입니다.

분산 시스템에는 일반적으로 하나의 이벤트 로그 (예 : Kafka)와이 로그를 서로 다른 서버에서 호스팅되는 여러 데이터베이스 / 스토어 (일반적으로 DB 복제본이 실제로 감속기)로 프로젝션 / 축소 할 수있는 여러 소비자가 있습니다. 따라서 분산 된 세계에서는로드 및 메모리 사용량이 분산됩니다. 반면 Redux에서는 모두 로컬 상태를 가진 수백 개의 위젯이 있고이 모든 것이 단일 브라우저에서 실행되며 모든 상태 변경에는 불변으로 인해 약간의 오버 헤드가 있습니다. 데이터 업데이트.

대부분의 경우이 오버 헤드는 큰 문제가 아니지만 텍스트 입력을 좋지 않은 상태 모양으로 마운트하고 느린 모바일 장치에서 빠르게 입력 할 때 항상 성능이 충분하지는 않습니다.

내 경험상 그 상태를 맨 위에서 렌더링하는 것은 편리하지 않고 항상 성능이 충분하지도 않습니다 (적어도 가장 빠른 VDom 구현이 아닌 React에서는). Redux는 connect 로이 문제를 해결하지만 연결 수가 증가함에 따라 병목 현상이 발생할 수 있습니다. 해결책 이

또한 ImmutableJS와 같은 영구 데이터 구조는 큰 목록의 임의 색인에 항목을 추가하는 것과 같은 일부 작업에서 항상 최상의 성능을 제공하지는 않습니다 ( 여기에서 큰 목록을 렌더링 한 경험 참조).

Redux는 편리하고 대부분의 사용 사례에 적합하기 때문에 이벤트 로그와 프로젝션을 모두 포함하지만 redux 외부에서 이벤트 로그를 유지하고 2 개 이상의 redux 저장소에 투영 할 수 있습니다. 이러한 모든 redux 저장소를 다른 키에서 컨텍스트에 반응하고 연결할 저장소를 지정하여 오버 헤드를 줄입니다. 이것은 절대적으로 가능하지만, 이제 저장소와 이벤트 로그를 명확하게 구분해야하므로 api와 devtools를 구현하기가 더 어려워집니다.

@jquense 에도 동의합니다.

쉬운 수분 공급, 스냅 샷, 시간 여행 등의 이점은 중요한 국가가 사는 다른 장소가없는 경우에만 작동합니다. React의 맥락에서 이것은 Store의 구성 요소에 적절하게 속하는 상태를 저장해야 함을 의미합니다. 모든 것을 Redux에 넣고 싶다면 종종 부담스럽고 ​​장황하게 끝나고 성가신 수준의 간접적 인 수준을 추가합니다.

모든 상태를 Redux 저장소에 마운트하려면 더 많은 상용구가 필요합니다. Elm 아키텍처는 아마도이 문제를보다 우아한 방식으로 해결하지만 많은 상용구가 필요합니다.

그러나 모든 상태를 제어하는 ​​것도 가능하거나 수행 할 수 없습니다. 때때로 우리는 선언적 인터페이스를 구축하기 어려운 기존 라이브러리를 사용합니다. 다음과 같은 일부 상태는 효율적인 방법으로 redux 저장소에 마운트하기가 어렵습니다.

• 텍스트 입력
• 스크롤 위치
• 뷰포트 크기
• 마우스 위치
• 캐럿 위치 / 선택
• 캔버스 dataUrls
• 직렬화 불가능 상태
• ...

내가 방금 본이 질문은 다음과 같습니다.

http://stackoverflow.com/questions/35328056/react-redux-should-all-component-states-be-kept-in-redux-store

UI 상태를 관리하는 것과 UI 상태가 구성 요소에 속해야하는지 아니면 스토어로 이동해야하는지에 대해 내가 본 혼란을 반향합니다. # 1287은이 질문에 대한 좋은 대답을 제공하지만 처음에는 그렇게 명확하지 않으며 논쟁의 여지가 있습니다.

또한 모든 구성 요소가 순수하고 자체 상태에서 발언권이없는 https://github.com/ericelliott/react-pure-component-starter 와 같은 것을 구현하려는 경우 방해가 될 수 있습니다. .

여러 세션의 데이터를 관리해야 할 때 redux의 단일 상태 트리를 사용하는 것이 어려웠습니다. 동일한 모양을 가진 임의의 수의 분기가 있고 각각 고유 한 식별자가 여러 개 있습니다 (데이터의 출처에 따라 다른 키를 사용합니다). 감속기 기능과 재 선택 기능의 단순성은 이러한 요구 사항에 직면했을 때 빠르게 사라졌습니다. 특정 분기를 대상으로하는 사용자 지정 getter / setter를 작성해야하는 경우 단순하고 구성 가능한 환경에서 지나치게 복잡하고 평평하다고 느꼈습니다. 여러 상점이 이러한 요구 사항을 해결하는 가장 좋은 옵션인지는 모르겠지만 세션 (또는 다른 동일한 모양의 데이터)을 단일 상태 트리로 관리하는 데 대한 일부 도구는 좋을 것입니다.

감속기 간의 상태 키 충돌 확률이 증가했습니다.
데이터 변형 및 선언은 데이터가 사용되는 코드와는 거리가 멀다 (코드를 작성할 때 변수 선언을 사용하는 위치 근처에 배치하려고합니다)

특정 사용 사례를 소개하겠습니다. 모든 UI 구성 요소가 순전히 작동하고 다양한 구성 요소에 대한 로컬 상태를 가질 방법이없는 virtual-dom과 함께 Redux를 사용하고 있습니다.

즉, 가장 어려운 부분은 애니메이션 상태를 묶는 것입니다. 다음 예제는 애니메이션 상태를 염두에두고 있지만이 중 대부분은 UI 상태 로 일반화 할 수 있습니다.

Redux에서 애니메이션 상태가 어색한 몇 가지 이유 :

• 애니메이션 데이터가 자주 변경됨
• 애니메이션 관련 작업은 앱의 작업 기록을 오염시켜 의미있는 방식으로 작업을 롤백하기 어렵게 만듭니다.
• Redux 상태 트리는 구성 요소 별 애니메이션이 많은 경우 구성 요소 트리를 미러링하기 시작합니다.
• animationStarted 또는 animationStopped 와 같은 기본 애니메이션 상태도 상태를 UI에 연결하기 시작합니다.

반면에 Redux 상태 트리 외부에서 애니메이션 상태를 구축하는 데는 확실히 어려움이 있습니다.

DOM을 조작하여 애니메이션을 직접 만들려고한다면 다음과 같은 것을주의해야합니다.

• virtual-dom diff는 노드에 설정 한 사용자 정의 스타일과 같은 애니메이션 조작을 고려하지 않습니다. DOM 노드에 일부 스타일을 설정 한 경우 제거하려면 직접 제거해야합니다.
• 문서 자체에서 애니메이션을 수행하는 경우 가상 DOM 업데이트에 대해 고통스럽게 인식해야합니다. 하나의 DOM 노드에서 애니메이션을 시작할 수 있지만 해당 DOM 노드의 콘텐츠가 애니메이션 중간에 변경되었음을 알 수 있습니다.
• 문서 자체에서 애니메이션을 수행하는 경우 노드에서 설정 한 가상 돔 덮어 쓰기 스타일 및 속성에주의해야하며 virtual-dom에서 설정 한 스타일 및 속성 덮어 쓰기에주의해야합니다.

그리고 만약 virtual-dom이 모든 DOM 조작을 처리하도록하려고하는데 (당신이해야합니다!) Redux에서 애니메이션 상태를 유지하지 않으면 다음과 같은 어려운 문제에 봉착하게됩니다 :

• 애니메이션 상태를 컴포넌트에 어떻게 노출합니까? 구성 요소의 로컬 상태? 다른 글로벌 상태?
• 일반적으로 상태 로직은 Redux 감속기에 있지만 이제는 상태에 대한 응답으로 어떻게 애니메이션되는지 구성 요소에 직접 많은 렌더링 로직을 추가해야합니다. 이것은 매우 어렵고 장황 할 수 있습니다.

이 문제를 해결하는 데 큰 진전을 이루는 react-motion과 같은 멋진 프로젝트가 현재 _for React_이지만 Redux는 React에만 국한되지 않습니다. 그렇게해서는 안됩니다. 많은 사람들이 자신의 뷰 레이어를 가져와 Redux와 통합하려고합니다.

궁금한 사람이라면 Redux + virtual-dom에 대해 제가 찾은 최고의 솔루션은 두 가지 상태 원자를 유지하는 것입니다. Redux는 핵심 애플리케이션 상태를 유지하고, 작업에 대한 응답으로 해당 상태를 조작하는 핵심 로직을 보유합니다. 다른 상태 애니메이션 상태를 유지하는 변경 가능한 객체입니다 (나는 mobservable을 사용합니다). 그런 다음 트릭은 Redux 상태 변경 _and_ 애니메이션 상태 변경을 모두 구독하고 UI를 두 기능으로 렌더링하는 것입니다.

/* Patch h for jsx/vdom to convert <App /> to App() */
import h from './h'
import { diff, patch, create } from 'virtual-dom'
import { createStore } from 'redux'
import { observable, autorun } from 'mobservable'
import TWEEN from 'tween.js'
import rootReducer from './reducers'
import { addCard } from './actions'
import App from './containers/App'

// Redux state
const store = createStore()

// Create vdom tree
let tree = render(store.getState())
let rootNode = create(tree)
document.body.appendChild(rootNode)

// Animation observable
let animationState = observable({
  opacity: 0
})

// Update document when Redux state 
store.subscribe(function () {
  // ... anything you need to do in response to Redux state changes
  update()
})

// Update document when animation state changes
autorun(update)

// Perform document update with current state
function update () {
  const state = store.getState()
  let newTree = render(state, animationState)
  let patches = diff(tree, newTree)
  rootNode = patch(rootNode, patches)
  tree = newTree
}

// UI is a function of current state (and animation!)
function render (state, animation = {}) {
  return (
    <App {...state} animation={animationState} />
  )
}

// Do some animations
function animationLoop (time) {
  window.requestAnimationFrame(animationLoop)
  TWEEN.update(time)
}
animationLoop()

new TWEEN.Tween(animationState)
      .to({ opacity: 100 }, 300)
      .start()

// Or when you dispatch an action, also kick off some animation changes...
store.dispatch(addCard())
/* etc... */

훌륭한 답변에 감사드립니다! 계속 오세요.

한 가지 주목할 점은 Redux가 _all_ 상태에 사용되도록 의도하지 않는다는 것입니다. 앱에 중요해 보이는 모든 것. 입력과 애니메이션 상태는 React (또는 다른 임시 상태 추상화)에서 처리해야한다고 주장합니다. Redux는 가져온 데이터 및 로컬에서 수정 된 모델과 같은 작업에 더 적합합니다.

헉헉

여러 세션의 데이터를 관리해야 할 때 redux의 단일 상태 트리를 사용하는 것이 어려웠습니다. 동일한 모양을 가진 임의의 수의 분기가 있고 각각 고유 한 식별자가 여러 개 있습니다 (데이터의 출처에 따라 다른 키를 사용합니다). 감속기 기능과 재 선택 기능의 단순성은 이러한 요구 사항에 직면했을 때 빠르게 사라졌습니다. 특정 분기를 대상으로하는 사용자 지정 getter / setter를 작성해야하는 경우 단순하고 구성 가능한 환경에서 지나치게 복잡하고 평평하다고 느꼈습니다.

사용 사례를 더 자세히 설명하는 문제를 만드시겠습니까? 누락 된 상태 모양을 다르게 구성하는 간단한 방법이있을 수 있습니다. 일반적으로 상태 모양이 같지만 다른 감속기에 의해 관리되는 여러 분기는 안티 패턴입니다.

뿡 빵뀨

감속기 간의 상태 키 충돌 확률이 증가했습니다.

어떻게 이런 일이 발생하는지 자세히 설명해 주시겠습니까? 일반적으로 모든 상태 슬라이스에서 단일 감속기를 실행하는 것이 좋습니다. 충돌은 어떻게 발생할 수 있습니까? 주에서 여러 번 통과하고 있습니까? 그렇다면 그 이유는 무엇입니까?

@gaearon @istarkov : 아마도 다양한 플러그인과 관련 라이브러리가 동일한 최상위 네임 스페이스를 위해

예, 이것이 @istarkov가 의미하는 것이

@gaearon

사용 사례를 더 자세히 설명하는 문제를 만드시겠습니까? 누락 된 상태 모양을 다르게 구성하는 간단한 방법이있을 수 있습니다. 일반적으로 상태 모양이 같지만 다른 감속기에 의해 관리되는 여러 분기는 안티 패턴입니다.

나는 기뻐할 것입니다! 잠시만 기다려주세요.

나는 그 분기를 관리하기 위해 단일 공유 감속기를 가지고 있지만 확실히 반 패턴으로 간주되었다고 생각합니다. 그럼에도 불구하고 redux가 제공하는 패러다임은 동일한 분기를 불변 상태로 직렬화 / 역 직렬화하는 완벽한 사용 사례와 그리 멀지 않은 것 같습니다. 특정 분기를 특정 키로 대상으로 지정하는 가정 된 논리로 reselect와 같은 것을 빌드하는 것이 redux의 정신에 어긋나는 이유를 모르겠습니다.

나는 그것에 대해 오프 스레드에 대해 이야기하는 것을 기쁘게 생각합니다. 나는 아주 잘 틀릴 수 있습니다.

@taggartbg : 코드가 여기에 어떻게 생겼는지 모른 채 전적으로 말하기. 당신은 이와 같은 상태를 다루려고하는 것에 대해 이야기하고 있습니까?

{ groupedData : { first : {a : 1, b : 2}, second : {a : 3, b : 4}, third : {a : 5, b, 6} }

각 작업의 일부로 그룹 별 ID 키를 사용하는 단일 감속기 기능을 사용하여 감속기 측에서이를 처리 할 수있는 것 같습니다. 사실, https://github.com/erikras/multireducer , https://github.com/lapanoid/redux-delegator , https://github.com/reducks/redux-multiplex , 또는 https://github.com/dexbol/redux-register?

또한 재 선택 측면에서 React-Redux가 이제 컴포넌트 별 선택기를 지원한다는 사실이 도움이 될 수 있습니다. 이는 컴포넌트 props를 기반으로 선택하는 시나리오를 개선하기 때문입니다.

@gaearon

한 가지 주목할 점은 Redux가 모든 상태에 사용되도록 의도하지 않는다는 것입니다. 앱에 중요해 보이는 모든 것. 입력과 애니메이션 상태는 React (또는 다른 임시 상태 추상화)에서 처리해야한다고 주장합니다. Redux는 가져온 데이터 및 로컬에서 수정 된 모델과 같은 작업에 더 적합합니다.

문서와 튜토리얼을 읽는 React 개발자는 이미이 임시 상태 추상화를 자유롭게 사용할 수 있으므로 Redux가 프로젝트에 적합한 위치를 고려할 때 이미 염두에두고있을 수 있습니다.

그러나 UI에 대한 기능적 접근을 원하는 React에 대한 경험이 거의 또는 전혀없는 개발자의 관점에서는 Redux에 속한 상태가 명확하지 않을 수 있습니다. 처음에는 Redux와 virtual-dom으로 충분했지만 애플리케이션이 복잡 해짐에 따라이 다른 "임시 상태 추상화"가 필요하게되었습니다. 기본 애니메이션 플래그가있는 애니메이션 감속기를 처음 추가 할 때 항상 분명하지는 않지만 나중에는 상당히 고통스러워집니다.

문서가 Redux에 적합한 상태와 다른 도구로 더 잘 해결되는 상태를 언급하는 것이 좋을 수 있습니다. React 개발자에게는 중복 될 수 있지만 다른 개발자가 Redux를 살펴보고 애플리케이션 아키텍처를 계획 할 때 염두에두면 매우 유용 할 수 있습니다.

편집 : 문제의 제목은 "모든 상태를 단일 불변 원자에 저장하는 단점은 무엇입니까?"입니다. 이 "단일 불변 원자의 모든 상태"는 Redux 트리에서 많은 잘못된 종류의 상태를 가져 오는 일종의 표현입니다. 문서는 개발자가 이러한 종류의 함정을 피하는 데 도움이되는 몇 가지 명시적인 예제를 제공 할 수 있습니다.

@gaearon 우리는 Cycle.js에서 단일 원자 상태와 파이핑 간의 구조적 차이점에 대해 흥미로운 대화를 나누었습니다. 여기 .

이것이 100 % Redux와 관련이 없다는 것을 알고 있지만 Observable 스트림을 앱 주변의 데이터 흐름으로 사용하는 구현과는 다른 관점을 제공하고 싶었습니다 (Cycle의 경우 순수 함수 집합 임).

Cycle의 모든 것이 Observable이기 때문에 상태를 한 경로 변경에서 다른 경로로 이동하는 데 어려움이있었습니다. 이것은 경로가 변경된 후 구독자가없는 Observable 상태 때문이며 단일 원자 상태를 구현하지 않는 이유를 생각했기 때문에 내 앱에서 상태가 변경 될 때마다 파이프를 우회하여 최상위 저장소로 다시보고합니다 ( view terrible 여기에 그림 ).

Cycle을 사용하면 드라이버에서 부작용이 발생하기 때문에 일반적으로 최상위 드라이버에서 구성 요소와 그 반대 방향으로 루프를 만들어야합니다. 그래서 저는 그냥 건너 뛰고 똑바로 위로 돌아가서 청취하는 구성 요소로 돌아가고 싶었습니다. Redux를 영감의 원천으로 삼았습니다.

옳거나 그른 경우는 아니지만 이제 파이핑을 수행하고 상태 드라이버를 알아 냈고 필요에 따라 상태를 다른 구성 요소로 파이프 할 수있는 능력이있어 리팩토링, 프로토 타이핑 및 강력한 이해에 매우 유연합니다. 각 국가의 원천, 각 소비자 및 서로에게 어떻게 도달했는지.

또한 응용 프로그램을 처음 접하는 사람들은 (물론 Cycle을 이해한다면) 쉽게 점을 연결하고 상태가 처리되고 파이프되는 방법과 코드에서이 모든 것을 염두에두고 시각적 표현을 매우 빠르게 그릴 수 있습니다.

이것이 완전히 문맥에서 벗어난 경우 미리 죄송합니다. 다른 패러다임이 비슷한 대화를 어떻게했는지 보여주고 싶었습니다.

뿡뿡

각 위젯은 둘 사이에 겹치지 않고 자체 상태를 유지해야합니다. 제품 팀은 각 위젯에 할당 될 가능성이 높으므로 다른 사람의 코드가 환경에 미치는 영향을 모를 수 있습니다.

나는 위젯이 자체 상태 (아마도 자체 (redux?) 저장소 일 수도 있음)를 가질 때 더 낫다고 생각하므로 모든 (매시업) 앱에서 독립적으로 작동하고 일부 속성 만받을 수 있습니다. 날씨 위젯에 대해 생각해보십시오. 자체적으로 데이터를 가져오고 표시 할 수 있으며 도시, 높이 및 너비와 같은 속성 만 수신 할 수 있습니다. 또 다른 예는 Twitter 위젯입니다.

@chicoxyzzy 관련 : https://github.com/rackt/react-redux/issues/278

좋은 토론!

주로 여러 앱 / 컴포넌트 / 플러그인을 결합하는 것이 불편합니다.

내가 만든 모듈을 가져 와서 다른 모듈 / 앱에 던질 수는 없습니다. 리듀서를 앱 스토어로 별도로 가져와야하고, 내 특정 키 아래에 넣어야하기 때문입니다. 모듈은 알고 있습니다. 이것은 또한 전체 상태에 연결되기 때문에 @connect 사용하는 경우 모듈을 복제하는 것을 제한합니다.

예를 들면 :

iMessage와 같은 메신저를 만들고 있습니다. redux 상태는 currentConversationId 등입니다. 내 Messenger 구성 요소에는 @connect(state => ({ currentConversationId: state.messenger.currentConversationId })) 있습니다.

이 Messenger 를 새 앱에 포함하고 싶습니다. 작동하려면 import { rootReducer as messengerRootReducer } from 'my-messenger' 를 combineReducers({ messenger: messengerRootReducer }) 에 추가해야합니다.

이제 다른 데이터를 가진 두 개의 <Messenger> 인스턴스를 앱에 갖고 싶은 경우 메신저 구성 요소에서 state.messenger 에 바인딩되어 있기 때문에 할 수 없습니다. 만들기상점의 특정 부분에 대해 작업하면 사용자 정의 @connect 있습니다.

또한 포함하는 앱에 my-messenger 모듈에 존재하는 특정 작업 이름이 있다고 가정하면 충돌이 발생합니다. 이것이 대부분의 redux 플러그인에 @@router/UPDATE_LOCATION 와 같은 접두사가있는 이유입니다.

무작위 / 미친 아이디어 몇 가지 :

1

@connect 는 상점의 특정 조각에 연결할 수 있으므로 state.messenger[0] / state.messenger[1] 와 같이 자체 데이터 조각에 연결하는 여러 <Messenger> 앱에 포함 할 수 있습니다. state.messenger[1] 여전히 state.messenger 계속 연결되는 <Messenger> 대해 투명해야하지만 포함하는 앱은 다음과 같이 슬라이스를 제공 할 수 있습니다.

@connect(state => ({ messengers: state.messengers }))
class App extends Component {
  render() {
    return (
      <div>
        {this.props.messengers.map(messenger =>
          <ProvideSlice slice={{messenger: messenger}}><Messenger /></ProvideSlice>
        }
      </div>
    )
  }
}

전역 정규화 된 엔티티를 사용할 때 문제가 있습니다. state.entities 도 있어야합니다. 따라서 슬라이스 상태와 함께 전체 상태가 어떻게 든 존재해야합니다. ProvideSlice 은 Messenger 의 @connect 에서 읽을 수있는 컨텍스트를 설정할 수 있습니다.

또 다른 문제는 <Messenger> 구성 요소에 의해 발생한 작업을 바인딩하는 방법이 해당 슬라이스에만 영향을 미치는 것입니다. @connect 아래에 ProvideSlice 이 (가) 해당 주에 대해서만 mapDispatchToProps 작업을 실행합니다.

2

store 및 reducer 정의를 결합하여 각 감속기가 독립형 일 수도 있습니다. 감속기가 뷰인 동안 컨트롤러처럼 소리를 저장합니다. React의 접근 방식, "모든 것이 구성 요소입니다"(angular 1.x의 컨트롤러 / 지시문과 달리)를 취하면 구성 요소와 해당 상태 / 동작이 진정으로 독립형이 될 수 있습니다. 정규화 된 엔티티 (예 : '글로벌 상태')와 같은 경우 React의 컨텍스트와 같은 것을 사용할 수 있으며 모든 작업 (예 : getState 의 thunk ) / 연결된 구성 요소를 통해 액세스 할 수 있습니다.

@elado 지금까지 본 가장 영리한 아이디어는 "제공자"를 염두에두고 설계하는 것입니다. https://medium.com/@timbur/react -automatic-redux-providers-and-replicators-c4e35a39f1

Thx @sompylasar. 나는 약간의로드 트립 atm에 있지만 기회가 생기면 이미 React와 Redux에 익숙한 사람들을 위해 공급자를 더 간결하게 설명하는 또 다른 기사를 작성할 계획입니다. 이미 익숙한 사람이라면 누구나 간단하고 간단합니다. :)

_ 댓글이 https://github.com/loggur/react-redux-provide/issues/8_ 로 이동했습니다.

@gaearon 은 여전히 ​​이것에 대한 당신의 생각을 듣고 싶습니다.

내 가장 큰 반려견은 동시에 두 개의 독립적 인 계층 (보기 및 감속기)이 있기 때문에 컨테이너 구성 요소를 구성, 재사용, 중첩 및 일반적으로 이동하는 것이 더 어렵다는 것입니다. 또한 Redux를 구현 세부 사항으로 사용하거나 Redux 친화적 인 인터페이스를 제공하려는 재사용 가능한 구성 요소를 작성하는 방법도 완전히 명확하지 않습니다. (다양한 접근 방식이 있습니다.) 또한 모든 작업이 어딘가에서 단락되는 대신 위로 "끝까지"올라 가야한다는 점에 감명을받지는 않습니다. 즉, React 로컬 상태 모델과 같은 것을보고 싶지만 리듀서에 의해 뒷받침되며, 아름다운 추상화가 아닌 실제 사용 사례에 맞게 조정되고 매우 실용적이기를 바랍니다.

@gaearon 이러한 시스템 구현을 시작하는 방법에 대한 아이디어가 있습니까?

@gaearon

즉, React 로컬 상태 모델과 같은 것을보고 싶지만 감속기에 의해 뒷받침됩니다.

까다로운 부분은 React 로컬 상태가 구성 요소의 수명주기와 연결되어 있다는 것이므로 Redux에서 로컬 상태를 모델링하려고하면 "마운팅"및 "마운트 해제"에 대한 설명이 있습니다. Elm은이 문제가 없습니다. 1) 컴포넌트에 라이프 사이클이없고 2) 뷰의 "마운팅"이 모델에서 파생 된 반면 React에서는 로컬 상태가 뷰가 마운트 된 _after_ 존재하기

그러나 당신이 언급했듯이 Elm 아키텍처 ( "모든 방법")는 자체 단점이 있으며 React의 업데이트 및 조정주기에 잘 맞지 않습니다 (예 : shouldComponentUpdate() 최적화를 자유롭게 사용해야합니다. ... render() 내부의 디스패치 메소드를 순진하게 "전달"하면 중단됩니다.)

특정 시점에서, 저는 감속기 + setState를 사용하고 하루라고 부르는 느낌이 듭니다. : D React 가 상태 트리 를

나는 이것이 @threepointone 이 https://github.com/threepointone/redux-react-local 로 해결하려는 것입니다.

@acdlite Elm의 개념적 모델은 로컬 상태에서 잘 작동하지만 라이브러리를 사용하고 마운트에 초점을 맞추고 시차 효과를 처리해야하는 실제 응용 프로그램에서 사용하기에는 정말 고통스러워 보입니다 ... https : //를 참조

@slorber 네 동의합니다. 본질적으로 내가 방금 말한 것이 아닙니까? :디

나는 당신의 우려가 약간 다르다고 생각합니다. _If_ (큰 "if") 당신이 React에서 Elm 아키텍처를 사용한다면, 우리는 여전히 생명주기에 접근 할 수 있고, 탈출 해치로서의 setState 등을 가지고 있기 때문에 당신이 언급 한 문제가 없을 것이라고 생각합니다.

예, 우리는 @acdlite 같은 페이지에 있습니다.
React가있는 Elm 아키텍처는이 문제를 해결할 것입니다.
Elm조차도 vdom 후크 사용을 허용 할 수 있기 때문에 미래에있을 수 있습니다.

그러나 Elm 아키텍처에는 꽤 많은 상용구가 필요합니다. 랩핑 / 랩핑 해제 작업에 Flow 또는 Typescript를 사용하지 않는 한 지속 가능하지 않다고 생각하며 @threepointone의 솔루션과 같이이 로컬 상태를 처리하는 더 간단한 방법을 갖는 것이 좋습니다

Elm 아키텍처에 대한 또 다른 우려는 중첩 된 동작이 로컬 구성 요소 상태에서 잘 작동한다는 것입니다.하지만 분리 된 구성 요소 간의 통신이 필요한 경우에는 그다지 좋은 생각이 아니라고 생각합니다. widget1이 widget2에 의해 발생한 일부 이벤트를 찾기 위해 깊게 중첩 된 조치를 풀고 검사해야하는 경우 커플 링 문제가 있습니다. 여기에 몇 가지 생각을 표현했으며 2 개의 "사서함"과 함께 Elm을 사용하는 것이 작업을 수행 할 수 있다고 생각합니다. 이것은 또한 redux-saga가 플랫 이벤트가있는 non-elm 아키텍처에서 도움이 될 수있는 것입니다.

확장 가능한 redux 앱을 설계하는 방법에 대한 좋은 아이디어를 가지기 시작하고 덜 바쁠 때 이에 대해 작성하려고 노력할 것입니다.

@gaearon 마지막 게시물에서 react-redux-provide 에 대해 이야기하고 있습니까? 당신이 대답에 따르면, 당신이 그것을 충분히 가까이 보지 않은 것이 분명하기 때문에 나는 묻는 것입니다.

또한 @acdlite 의 상태 트리 외부화에 대한 언급과 관련하여 이것은 제공 업체가 해결하도록 설계된 문제입니다.

provide 데코레이터가 제공하는 API는 확실히 추상화이며 예, 현재 redux 에 종속되어 있지만 redux 에 종속되어 있다고 생각하는 것은 잘못된 방법입니다. React의 context 는 아직 완전히 개발되지 않았기 때문에 구성 요소와 상태 트리 간의 "접착제"에 불과하므로 생각해보십시오. actions 및 reducers (즉, 상점의 상태)를 통해 상태 트리를 조작하고 표현하는 이상적인 방법으로 생각하십시오. props . 본질적으로 선언 actions 및 reducers 로 propTypes (및 / 또는 contextTypes 어떻게 당신에게 유사한 미래에) import 다른 어떤 앱 내에서. 이렇게하면 모든 것이 추론하기가 엄청나게 쉬워집니다. React의 context 는 잠재적으로 이러한 기본 기능을 포함하도록 발전 할 수 있으며,이 경우 grep하고 @provide 및 import provide from 'react-redux-provide' 제거하는 데 전체 2 초가 걸립니다. 그런 다음 더 이상 의존하지 않는 간단한 구성 요소를 남겼습니다. 그리고 그것이 결코 일어나지 않는다면, 모든 것이 완벽하고 예측 가능하게 계속 작동 할 것이기 때문에 큰 문제는 아닙니다.

나는 당신이 문제를 지나치게 단순화하고 있다고 생각합니다. 여전히 장착 및 분리 문제를 해결해야합니다.

@acdlite 예제가 있습니까?

당신이 언급하고있는 것 중 하나는 검색 (예를 들어) 인 경우 props 일부를 기반으로 일부 데이터베이스에서 id 이든, (당신이 생각할 수있는 거의 모든 다른 실용적인 응용 프로그램들)이 공급자를 통해 쉽게 달성 할 수 있습니다. 작업중인 다른 작업을 마치면 얼마나 쉬운 지 보여 드리게되어 기쁩니다. :)

흥미로울 수 있습니다 : 반응 상태 구현 비교 .
Elm, Redux, CycleJS ... (진행중인 작업)

여러 매장에 대한 또 다른 가능한 요구 사항은 여러 _ 타임 라인 _, _ 시간 여행 _, 저장 위치 및 저장 빈도가 가능하고 필요할 때입니다. 예를 들어, 단일 사용자에만 해당하는 user data 및 user actions , 사용자 그룹에 해당하는 common data 및 group actions (예 : 공유 다중 사용자 프로젝트 또는 문서). 이렇게하면 실행 취소 할 수있는 항목 (개인 데이터 변경)을 수정 된 항목 (다른 사용자가 이미 추가 한 편집)과 쉽게 분리 할 수 ​​있으며 다른 저장 및 / 또는 동기화주기를 쉽게 사용할 수 있습니다.

우리는 angular 2.0 개발 마인드 세트를 가진 angular 1.x 애플리케이션의 설계 / 초기 개발 단계에 있으며 redux를 사용할 생각입니다. 과거에는 몇 가지 일반적인 디스패치와 일부 전용 디스패치에 응답하는 여러 매장에서 플럭스를 사용해 왔습니다.

Redux는 나에게 훌륭해 보이지만 전체 애플리케이션에 대해 단일 스토어 개념을 추론 할 수는 없습니다. 다른 사람들도 위에서 지적했듯이, 우리는 서로 다른 소비자 응용 프로그램에서 호스팅되어야하고 이들 각각에 대한 전용 데이터 저장소가 필요한 많은 큰 위젯이 있습니다.

감속기를 분할하여 사용하는 기능 / 위젯과 함께 사용할 수 있지만 스토어를 만들 때 모두를 클럽 화해야합니다. 우리는 우리 위젯이 신경 쓰지 않는 리듀서에 대한 직접 / 간접 참조없이 존재하는 것을보고 싶습니다.

우리는 앱에서 redux를 사용하기 전에 그러한 상황에서 모범 사례를 설명하기 위해 문서 형태의 지침이나 의견을 정말로 고대하고 있습니다. 어떤 도움이라도 정말 감사하겠습니다. 감사.

@VivekPMenon : 당신의 구체적인 관심사는 무엇입니까? 상태 트리의 크기? 네임 스페이스 작업 / 리듀서를 격리 할 수 ​​있습니까? 감속기를 동적으로 추가하거나 제거 할 수 있습니까?

그만한 가치를 위해 방금 Redux 애드온 생태계를 분류하는 링크 목록을 완성했습니다. 이러한 격리 / 복제 / 범위 지정 개념 중 일부를 해결하려는 많은 라이브러리가 있습니다. 감속기 페이지 와 로컬 / 컴포넌트 상태 페이지 를 살펴보고 이러한 라이브러리가 사용 사례에 도움이 될 수 있는지 확인하는 것이 좋습니다.

@markerikson. 답장을 보내 주셔서 감사합니다. 내 혼란은 대부분 두 번째 지점 (격리)입니다. 우리 팀 중 하나가 플럭스 기반의 위젯 A를 만들고 상태를 관리하기 위해 저장소를 사용해야한다고 가정합니다. jspm / npm 패키지를 만들고 배포한다고 가정합니다. 위젯 B를 생성하는 다른 팀의 경우도 마찬가지입니다. 이들은 독립적 인 위젯 / 패키지이며 서로에 대한 직접 / 간접 종속성을 가질 필요가 없습니다.

이 맥락에서 일반적인 플럭스 세계에서. 위젯 A와 B는 패키지 내에 자체 저장소를 가지고 있습니다 (몇 가지 일반적인 작업을 수신 할 수 있지만 일반적이지 않은 작업이 더 있다고 가정합니다). 그리고 두 위젯 모두 전역 디스패처에 종속됩니다. redux 패턴에서 그 저장소는 (물리적으로) 어디에서 생성됩니까? 위젯 A와 B UI 구성 요소는 모두 변경 사항을 수신하고 상태를 가져 오기 위해 저장소 인스턴스를 사용해야합니다. 정기적으로 그들은 자체 매장 인스턴스에서 작동합니다. 이 상황에서 단일 상점 개념이 어떻게 작용할 것인지 시각화하려고합니다.

@VivekPMenon 이것은 우리 중 일부가 해결하려는 유효한 질문입니다.

https://github.com/slorber/scalable-frontend-with-elm-or-redux에서 몇 가지 통찰력을 얻을 수 있습니다.

또한 여기에서 Redux-saga에 대한 내 anwser를 살펴보십시오 : http://stackoverflow.com/a/34623840/82609

@slorber 지도 https://github.com/slorber/scalable-frontend-with-elm-or-redux

@taggartbg 결국 이슈를 열었습니까? 나는 비슷한 것에 관심이 있습니다-다른 독립적 인 하위 트리를 가진 반응 라우터를 가질 때, 새로운 분기로 이동하는 동안 이전 경로의 상태를 유지하는 것이 문제라는 것을 발견했습니다.

@slorber

redux saga는 아주 많은 것을 담은 멋진 프로젝트라고 말하면서 시작하겠습니다. 이것은 결코 그것을 줄이려고하지 않습니다.

하지만 현재 상태에서는 어떤 프로젝트에서도 사용하지 않을 것입니다. 몇 가지 이유가 있습니다.

사가는 무국적자입니다

생성기의 상태를 직렬화 할 수 없습니다. 실행중인 동안에는 의미가 있지만 완전히 사가의 상태에 묶여 있습니다. 이로 인해 일련의 제한이 발생합니다.

• 시간 여행 발전기를 사용할 수 없습니다
• 사가의 현재 상태로 이어진 경로를 추적 할 수 없습니다.
• 초기 상태를 정의 할 수 없습니다.
• 애플리케이션의 상태 [*]에서 비즈니스 로직을 분리 할 수 ​​없습니다.
• 사가를 저장할 수 없습니다

[*] 이것은 애플리케이션 모델의 정의 내에서 비즈니스 로직을 정의하는 것으로 해석 될 수 있으며, MVC의 M과 C를 동일한 것으로 만들어 반 패턴으로 간주 될 수 있습니다.

디스패치 작업은 비 결정적입니다.

redux 사용의 큰 장점 중 하나는 상태가 작업에 어떻게 반응하는지에 대한 간단한 이해를 유지하는 것입니다. 그러나 redux-saga는 어떤 부분에서 시작하는지 알 수 없기 때문에 예기치 않은 결과가 발생하기 쉬운 작업을 만듭니다.

직렬화 가능 상태

문제는 사가의 현재 상태가 애플리케이션의 현재 상태에 영향을 미치고 사람들은 상태를 직렬화 가능하게 유지하는 것에 대해 스트레스를 받는다는 것입니다.하지만이를 사가로 어떻게 변환합니까? 상태를 완전히 직렬화 할 수 없다면 실제로 직렬화하는 것이 아닙니다. 기본적으로 saga를 복구하지 않고는 응용 프로그램의 상태를 복구 할 수 없습니다.

상태에 논리를 저장하는 것은 나쁘고 제 생각에는 이것이 redux saga 가하는 일입니다.

응용 프로그램의 상태가 _your_ 응용 프로그램에 고유하다고 가정해도 괜찮습니다. 즉, _your_ 애플리케이션 위에서 작동하는 한 애플리케이션의 상태를 예측할 수 있다고 가정해도 좋습니다. 이는 실제로 로직을 저장하지 않고 애플리케이션의 작동 방식을 결정하는 저장소 정보를 유지할 수 있음을 의미합니다.

뿡뿡

나는 당신의 우려를 이해합니다. redux-saga 문제를 살펴보면 이러한 문제가 논의되고 해결책이 있음을 알 수 있습니다.

또한 redux-saga는 제너레이터로 구현하기로 선택했지만 saga 패턴을 구현하는 것이 전혀 요구 사항은 아니며 장단점이 있습니다.

redux-saga 내부에서 redux 상태를 사용할 수있는 선택 효과가 있으므로 생성기 내부에서 상태를 숨기고 싶지 않다면 단순히 redux-store에 직접 saga 상태를 넣을 수 있지만 더 많은 작업이 필요합니다.

saga의 실행을 추적 할 수있는 saga devtools가 있습니다.

시간 여행에 대한 가능한 솔루션이 있지만 아직 구체적인 구현은 없습니다.

권리. 꽤 긴 주제이고 매우 흥미 롭습니다. 저는 다양한 국가 관리 접근 방식을 비교해 왔습니다.

비교하는 동안 몇 가지 사항을 염두에두고 있습니다.

1. 진실의 단일 소스
2. 서버 측에서 렌더링하고 클라이언트 측에서 초기 데이터를 공급하는 것이 얼마나 쉽고 / 어려웠습니까?
3. 실행 취소 / 다시 실행과 같은 devtools 및 다시로드 후 지속적인 기록 저장.
4. 애니메이션, 애니메이션, 애니메이션. 나는 항상 스스로에게 _ "어떻게 애니메이션이 솔루션 a 또는 b와 함께 작동 할 것인가"_라고 자문합니다. 제가 개발중인 제품이 UX 중심이기 때문에 이것이 제게 핵심입니다. @jsonnull 이 가진 많은 혼란을 공유합니다.
5. 다른 앱 내에서 구성 요소 재사용
6. 무결성을 유지하기 위해 참조 된 데이터의 수화 (_ 중요한 고통 _) (서버 측 또는 기타 데이터 소스에서 초기 데이터 공급과 관련됨)
7. 이와 같은 토론을위한 다른 개발자 커뮤니티

그래서 이것이 제가 국가 관리에 대해 생각할 때주의하는 점입니다. Redux는 대부분의 상자를 선택하여 승자입니다. 나는 Redux를 꽤 잘 알고 있으며 클라이언트 측 js 영역에서 침착하게 숨을 쉬게 한 첫 번째 일이었습니다.

내가 살펴본 가장 주목할만한 다른 프로젝트는 SAM 패턴 (_ 마인드 셋에 들어가기가 어렵고 도구가 없음 _) 및 Mobx (_ 변경 가능한 저장소로 알려져 있음 _)입니다.

둘 다 단일 소스의 진실이라는 생각을 공유하고 있으며 그들이 어떻게 처리하는지 보는 것이 흥미 롭다고 생각합니다.

Mobx에 대한 나의 (물론 제한적) 연구 결과는 다음과 같습니다.

1. Mobx (Redux와 마찬가지로)는 단일 소스 소스를 옹호하지만 관찰 가능한 속성을 가진 클래스입니다. 이 개념은 전체적으로 redux 및 flux와의 차이점을 만듭니다.
   
   
   
   1. Mobx는 또한 하위 상점 (_ 중첩 / 글로벌 단일의 일부 _)을 옹호합니다. 나에게 그것은 클라이언트 측 스키마를 정의하는 것과 매우 흡사합니다. 서버에도 스키마가있을 수 있으므로 약간 짜증이납니다. redux-orm 와 유사점이 보입니다. AFAIK 하위 저장소는 소품으로 구성 요소에 전달됩니다 (이렇게하면 구성 요소가 상태를 소품에 매핑하거나 전역 트리의 특정 키에 의존하지 않음). 그러나 단일 속성을 전달하면 "속성"에 대한 내 생각이 깨집니다. 구성 요소에 필요한 내용을 설명해야합니다. 이것은 실제로 React propTypes 를 사용하여 전달되는 상점의 모양을 정의 할 수 있다면 문제가 될 것이라고 생각하게합니다. 또한 저장소 및 하위 저장소를 클래스로 사용하면 정규화없이 직접 데이터를 참조 할 수 있지만 다음과 같은 이유로 초기 데이터를 공급하려는 경우에는 의미가 없습니다.
   
   
   2. 그러나 클래스로 저장한다는 개념은 개발자가 기본적으로 직렬화를 수행 할 수 없다는 것을 의미합니다. 즉, 초기 데이터를 공급하려는 경우 수행 할 작업입니다.
   
   
2. 변경된 상태의 스냅 샷을 찍어 기록 및 실행 취소 / 다시 실행을 수행 할 수 있습니다. 그러나 직렬화 기, 직렬화 기 해제기를 직접 작성해야합니다. 예는 다음과 같습니다. https://github.com/mobxjs/mobx-reactive2015-demo/blob/master/src/stores/time.js
3. serializer 작성의 좋은 점은 항목을 생략 할 수 있다는 것입니다. 비 영구적 인 애니메이션 관련 데이터를 저장하기에 좋은 장소처럼 보입니다. 따라서 직렬화하면 무시하고 애니메이션 단계로 가득 찬 다시 실행 / 실행 취소가 없습니다.
4. Mobx는 reselect + connect 데코레이터와는 반대로 (스토어의 방법으로) 스토어에 데이터 파생물을 보관하는 것을 옹호합니다. 이것은 나에게 다소 잘못된 것 같습니다.
5. 관찰 가능한 특성으로 인해 mobx는 효율적인 순수 구성 요소를 쉽게 정의 할 수 있습니다. 속성의 얕은 비교는 어쨌든 내용을 관찰 할 수 있기 때문에 문제가되지 않습니다.

SAM과 Redux를 비교하면 논리가 어떻게 흐르는 지 생각하고 싶습니다.

1. Redux :
   
   
   
   1. 상점 정의
   
   
   2. 상점 변경 (감소 기)을 처리하는 함수 정의
   
   
   3. 모든 상점 변경에 대한 이벤트 (redux 작업) 식별자 (redux 작업 유형)를 정의하고 일치 할 때 특정 감속기를 실행합니다.
   
   
   4. 저장소를 구성 요소 컨테이너 속성에 매핑하고, 선택적으로 사용자 상호 작용 (클릭, 유형, 스크롤 등) 처리기를 이벤트를 트리거 / 디스패치 작업을 단순히 트리거하는 함수로 전달합니다.
   
   
   5. 구성 요소가 모든 감속기와 일치하는 이벤트 (redux 작업)를 트리거합니다.
   
   
   6. 새 상태로 렌더링합니다.
   
   
2. SAM :
   
   
   
   1. 상점을 정의하십시오.
   
   
   2. 상점에 대한 접근 자 / 세터 기능을 정의하십시오. 이 setter는 모든 데이터를 받아들이고 순전히 데이터를 저장소에 저장할 위치와 서버에서 데이터를 요청해야하는지 아니면 유지해야하는지 파악하려는 데이터를 기반으로합니다. 데이터로 무엇을해야하는지 알아내는 것이 항상 검사만으로 가능한 것은 아니기 때문에 때때로 식별자 / 플래그가 사용됩니다 (예 isForgottenPassword ). 이 setter는 데이터의 유효성을 검사하고 대신 오류를 저장하기위한 것이기도합니다. setter가 완료된 후-> 새 상태로 다시 렌더링합니다.
   
   
   3. 데이터 조각을 받아들이고 변환 (redux 감속기 대신)하는 함수를 정의하고 변환 된 데이터를 전달하는 setter를 실행합니다. 이러한 기능은 이제 상점의 모양에 대한 아이디어를 가지고 있습니다. 그들은 전달 된 데이터 만 알고 있습니다.
   
   
   4. 저장소 데이터를 구성 요소 컨테이너 속성에 매핑하지만 사용자 상호 작용 처리기 (클릭, 유형, 스크롤 등)의 처리기를 전달해야합니다. 이들은 실제 함수 (redux에서 리듀서라고 함)이며 디스패치 호출을 실행하는 함수가 아닙니다.
   
   
   5. 참고 : 액션 디스패치, 리듀서의 직선 전달이 없습니다.
   
   

따라서 redux, SAM 및 Mobx는 모두 상태를 한곳에 유지합니다. 그들이하는 방식은 그들 자신의 좌절을 가져옵니다. 아무도 지금까지 redux와 생태계를 이길 수 없습니다.

내가 본 가장 큰 단점은 직렬화 할 수없는 상태를 처리한다는 것입니다.
제 경우에는 플러그인 API가 있으므로 Redux와 할 일이 없지만 애플리케이션과 상호 작용해야하는 동작과 로직이 있습니다. 그래서 기본적으로 주어진 상태를 기반으로 한 무리의 클래스를 처음에 다시 만들어야합니다.

이러한 종류의 직렬화 불가능 상태를 더 나은 방식으로 처리하는 방법에 대해 몇 가지 개념을 연구하고 있습니다. 주어진 상태에서 다시 생성하는 것을 포함합니다. 나는 이미 함수 / 객체 참조를 제외한 모든 것을 저장소로 다시 옮겼습니다. 남은 것은 내 애플리케이션 및 내 작업과 상호 작용하는 정의 된 API가있는 자체 수명주기가있는 개체입니다. -UI 렌더링이 아니라 사용자 정의 로직에 대한 React 구성 요소와 비슷합니다.

여러분 이 Erik Meijer의이 기사를 읽었는지 모르겠습니다. 간단한 인용문 :

대중적인 믿음과는 달리, 상태 변수를 불변으로 만드는 것은 용납 할 수없는 암시 적 명령 효과를 제거하는 것과 거의 비슷하지 않습니다.

아마도이 모든 불변성 넌센스를 다시 살펴볼 때일 것입니다. 모든 사람들은 단일 상태 트리의 크기가 커지면 성능이 저하된다고 말할 것입니다. SAM 패턴 은 변이를 프로그래밍 모델의 기본 클래스 시민으로 만듭니다. Sagas가 더 이상 필요하지 않은 것에서 효과 (예 : 가져 오기)를 추적하는 데 필요한 모든 보조 상태 머신에 이르기까지 많은 단순화가 발생합니다.

이 기사는 당신에게 유리하게 주장하지 않습니다. Erik Meijer는 "이 불변성 넌센스"를 재검토 하고이를 완전히 수용합니다 . 그는 상태 변이를 제거 하는 것이 기본적인 첫 번째 단계 이며 근본적이지만 충분하지는 않다고 주장합니다. 그의 궁극적 인 목표는 모든 상태 관리를 쓸모 없게 만드는 암시 적 부작용을 완전히 제거하는 것입니다 (관리 할 상태가 없습니다!).

나는 Erik Meijer의 작업의 팬이며 그가 말하는 모든 것을 열심히 읽고들을 것이며, 그가 나와 같은 사업, 기술 및 지적 제약 하에서 운영되지 않는다는 것을 명심할 것입니다.

소프트웨어 엔지니어링의 핵심 문제는 모든 사람이 할당 IS-A 돌연변이를 믿는 것처럼 보인다는 것입니다. 프로그래밍 언어는 할당 만 지원하며 변이는 프로그래머의 해석에 맡겨집니다.

여러 할당에 함수 래퍼를 추가하는 것이 자동으로 상태를 변경하는 가장 좋은 방법이되는 것은 아닙니다. 그건 말도 안돼.

(Application) State Mutation 뒤에는 이론이 있습니다. TLA +라고합니다. 이상하게도 ... Erik은 TLA +를 언급하지 않습니다.

JJ-

많은 혼란이있는 것 같으니 자세히 설명하겠습니다. Erik의 논문은 명령형 프로그래밍 언어가 변이 상태와 관련하여 다소 손상되었음을 설득력있게 보여줍니다. 나는 모두가 그것에 동의한다고 믿습니다.

문제는 어떻게 해결해야하나요? 이것이 " 첫 번째 원칙 "접근 방식이 필요한 문제라는 데 동의하지 않습니까?

컴퓨터 과학에서 우리 모두가 동의 할 수있는 하나의 원칙이 거의 있다고 Lamport 박사는 다음과 같이 말합니다. "컴퓨터 과학의 대부분은 상태 기계에 관한 것입니다." "그러나 컴퓨터 과학자들은 계산을 설명하는 데 사용되는 언어에 너무 초점을 맞추고 있기 때문에 그 언어가 모두 상태 기계를 설명한다는 사실을 거의 알지 못합니다."

실제로 모든 프로그래밍 언어를 사용하면 의미에 관계없이 "상태 머신"을 지정할 수 있습니다. 불행히도 많은 프로그래밍 언어는 "상태-작업"보다는 "작업"에 편향되어 있습니다. 그것은 정당한 이유가 있습니다. (상태 머신의 상태는 대부분 무시 될 수있는) 액션 기반 형식주의로 훨씬 더 효율적으로 코딩되는 많은 종류의 문제가 있습니다. 당신이 그것들을 무시할 때, 본질적으로 당신은 주어진 상태에서 모든 행동이 가능하다고 말하는 것입니다. 우리 모두가 알고있는 것은 일반적으로 사실이 아닙니다.

Erik의 haha ​​예제에 대해 원하는만큼 웃을 수 있습니다.
// prints Ha var ha = Ha(); var haha = ha+ha;

그러나 그가 말하는 것은 주어진 상태에서 잘못된 행동을하고 있다는 것입니다. 그 이상도 그 이하도 아닙니다.

함수형 프로그래밍이 테이블에 가져 오는 것은 무엇입니까? 전혀 그렇지 않습니다. 행동을 취하는 것과 그로 인한 결과 사이의 관계를 매우 복잡한 방식으로 표현합니다. 마치 거대한 미로에 화살 (스마트 모나 딕 화살도)을 던지고 목표물을 맞추기를 바라는 것과 같습니다.

TLA +는 효과를 처리하는 훨씬 더 자연스러운 방법을 제공합니다. 먼저 단계가 무엇인지, 돌연변이가 행동과 어떻게 관련되는지에 대한 명확한 개념이 있기 때문입니다. TLA +를 무시할 수는 있지만 지구가 평평하고 우주선을 조종하는 것이 정말 어려웠다 고 가정하여 달에 로켓을 보내려고했다고 불평하는 것과 같습니다. 우리는 사람들이 현실을 왜곡 할 수 있다고 믿는 세상에 살고 있다는 것을 알고 있습니다.

다시 말하지만, Erik이 TLA +에 대해 어떻게 생각하는지 정말 궁금합니다. LinkedIn에서 그와 연결하여 질문을했습니다. 답을 얻지 못했습니다 ... 램 포트 박사가 튜링 상을 받았지만 시간을 할애 할 가치가 없을 것입니다.

솔직히, @jdubray , 당신은이 시점에서 경계선 트롤링을하고 있습니다. 이 스레드, 다른 문제 및 다른 곳에서 주장을 수십 번 반복했습니다. Dan과 Redux 커뮤니티를 모욕하고 자격 증명을 흔들어 "TLA +"와 "Lamport"라는 단어를 마치 성배와 생명, 우주 및 모든 것에 대한 답인 것처럼 계속 호출합니다. 당신은 SAM이 Redux보다 훨씬 우월하다고 주장했지만, 증거를 보여 달라는 수많은 초대에도 불구하고 의미있는 비교 앱 방식으로 많은 것을 작성하지 않았습니다. 당신은 지금까지 아직 확신하지 못하는 사람의 마음을 정말로 바꾸지 않을 것입니다. 솔직히 좀 더 생산적인 일을하면서 시간을 보내실 것을 권합니다.

이 시점에서 스레드를 닫을 것입니다. 댓글은 계속 될 수 있지만 여기에서 실행 가능한 것은 없습니다.

@markerikson 제목이 아무데도 가지
@antitoxic (말장난 의도 없음) 외에도 개입으로 인해 다른 문제가 얼마나 나빴는지 알고 있으므로 더 이상들을 필요가 없습니다.

괜찮아 마크 내 댓글을 삭제할 수 있는데, 왜 이렇게 화려한 대화를 망칠 까?

@jdubray 당신만이

나는 TLA + 또는 좋지 않은 것을 말하지 않으며 아마도 미래에 누군가가 당신이 그것을 파는 것보다 더 나은 일을 할 것입니다. 우리가 이해하는 데 전혀 도움이되지 않는 것은 당신이 설명하는 방식 일 뿐이며, 당신의 영구적 인 겸손한 어조는 TLA +에 대해 배우는 데 시간을 투자하도록 초대하지 않습니다.

Erik의 논문은 명령형 프로그래밍 언어가 변이 상태와 관련하여 다소 손상되었음을 설득력있게 보여줍니다. 나는 모두가 그것에 동의한다고 믿습니다.

실제로 모든 게시물에서 항상 I believe everyone agrees on that 와 같은 용어를 사용합니다. 이것은 사람들에게 좋거나, 도움이되거나, 환영하는 것이 아닙니다. 우리는 모두 기본적으로 동의하지 않으며, 대부분은 Erik의 논문을 읽지 않았고 읽지 않을 것입니다. 사람들을 환영하는 방식으로 설득 할 수없고, 전에 많은 종이를 읽어달라고 요청하지 않고, 그들이 당신과 동의하지 않거나 동의하지 않으면 멍청하게 느끼게한다면 그것은 당신의 아이디어를 전파하는 데 도움이되지 않을 것입니다.

TLA +를 무시할 수는 있지만 지구가 평평하고 우주선을 조종하는 것이 정말 어려웠다 고 가정하여 달에 로켓을 보내려고했다고 불평하는 것과 같습니다.

이것은 확실히 첫 번째 원칙이 아닌 비유처럼 보입니다. 진지하게, 당신은이 진술이 "흥미로운 토론"으로 간주되어야한다고 생각합니까?

TLA +에 대한 모든 관심을 독점하고 실제로 TLA +에 관심이없는 사람들이 더 구체적인 무언가로 달에 로켓을 보내려고하는 것을 막기 때문에 논의가 실제로 더 화려하다고 생각합니다. 사람들은 Redux처럼 이해할 수 있습니다.

여전히 TLA +가 그만한 가치가 없다고 말하는 것은 아닙니다. 단지 잘못된 방식으로 잘못된 사람들에게 말하는 것입니다. Erik이 당신에게 대답하지 않았다면 그것은 그가 당신을 이해할 수 없기 때문일까요? 어쩌면 당신은 램 포트만이 당신을 이해할 수있을 정도로 영리한가? 어쩌면 미래에 튜링 상을받을 수 있을까요? 잘 모르겠지만 한 가지 확실한 것은 현재 토론이 테이블에 아무것도 가져 오지 않는다는 것입니다.

@gaearon을 좋아하고 egghead 용 TLA + / SAM 비디오 자습서를 만들 수도 있습니다. 2 시간 미만의 동영상에서 매우 간단한 방법으로 아이디어를 설명 할 수 있고 마지막에 패턴이 클릭하고 개발자에게 유용하다고 느끼면 승리합니다. Redux는 많은 사람들을 위해 그렇게했습니다. SAM / TLA +가 Redux보다 나은 이유를 이론적으로 설명하기 위해서만 "시도"하고 끔찍한 TodoMVC 구현을 제공했습니다. 우리는 여기 CS 연구자이며 콘크리트 재료가 필요합니다. Redux로 작성된 앱과 SAM으로 작성된 앱을 보여 주실 수 있습니까? 사람들이 실제로 SAM 구현이 더 낫다고 느낄 수 있습니까? 지금까지는 그렇지 않았습니다.

@Niondir 상태를 복구해야하는 경우 sagas를 사용하는 방법을
따라야 할 패턴이나 규칙에 가깝습니다.

• 각각 하나의 put 이상이 없도록 sagas를 분리하십시오. put 이상의 사가가있는 경우 분할하고 call 효과로 연결합니다. 예

function* mySaga() {
  yield put(action1());
  yield put(action2());
}

// split into

function* mySaga() {
  yield put(action1());
  yield call(myNextSaga);
}

function* myNextSaga() {
  yield put(action2());
}

• take 효과가있는 사가는 take 와 사가의 시작점을 따르는 논리로 분할되어야합니다. 예

function* mySaga() {
  yield take(ACTION);
  // logic
}

// split it into

function* rootSaga() {
  yield takeLatest(ACTION, mySaga);
}

function* mySaga() {
  // logic
}

• 각 사가에 대해 일종의 "체크 포인트"기능을 생성합니다. 즉, 초기화시 상태에서 읽고 거기에서 call 필요한 사가를 읽습니다.

function* rootSaga() {
  // emit all forks and take effects that need to run in the background
  yield call(recoverCheckpoint);
}

function* recoverCheckpoint() {
  const state = yield select();
  if (state.isFetching) {
    // run the saga that left the state like this
  }
}

이것이 작동하는 이유에 대한 설명은 일반적으로 사실 인 일련의 가정을 기반으로합니다.

• take 효과는 상점에 전달 될 작업이 필요합니다. 사용자가 페이지와 상호 작용하거나 sagas가 이미 실행 중일 때까지 유휴 상태로 유지되기 때문에 복구중인 경우에도 항상 초기화시 이러한 sagas를 호출하는 것이 안전합니다.
• 사가 당 하나 이상의 put 호출을 허용하지 않으면 상태의 원자 적 변경이 허용됩니다. 동일한 방식으로 사가가 해당 용량으로 제한되는 단일 방식으로 만 상태를 변경할 수 있습니다. 사가와 액션 디스패치 사이의 상관 관계.

이런 식으로 사가를 나누는 것도 긍정적 인 효과가 있습니다.

• Sagas는 더 재사용 가능합니다.
• Sagas는 더 쉽게 변경됩니다
• Sagas는 이해하기 더 쉽습니다.

하지만 @slorber :

• (10 분) 소개 동영상은 여기 : https://www.youtube.com/watch?v=lMgSS_b98S8
• 비디오에서 제가 이야기하는 코드 샘플은 다음과 같습니다 : https://github.com/jdubray/sam-samples/tree/master/js-rectangle

많은 사람들이이 "낚시 게임"샘플이 동적 상태 표현 및 "다음 작업 조건 자"를 포함하여 SAM이 전체적으로 작동하는 방식을 직접 보여주기 때문에 코딩에 매우 흥미 롭다고 생각합니다. NAP는 Sagas의 필요성을 완화하고 단일 상태 트리 인 Redux 원칙 # 1을 위반할 필요가 없습니다.하지만 제가 무엇을 알고 있습니까?

가끔 Ableton Live를 사용할 때 "Ableton Live GUI를 React / Redux 앱으로 작성하는 것이 가능할까요?"라는 생각이 떠 오릅니다. 대답은 '아니오'라고 생각합니다. 수용 가능한 성능을 얻기가 너무 어려울 것입니다. Qt로 작성된 이유와 Qt에 신호 / 슬롯 아키텍처가있는 이유가 있습니다.

Meteor와 함께 React / Redux를 사용하고 있습니다. 콜백에 대한 Redux 작업을 Mongo.Collection.observeChanges 에 디스패치하여 Mongo 문서를 Immutable.js 상태에 저장합니다. 최근에 수천 개의 문서를 구독 할 때 Meteor가 초기 구독 결과를 하나씩 보내면서 수천 개의 Redux 작업이 발송되어 수천 개의 Immutable.js 작업과 수천 개의 rerenders가 빠르게 발생했기 때문에 UI가 시작시 매우 느리다는 것을 발견했습니다. 가능한 한. 확실하지는 않지만 RethinkDB도 이런 식으로 작동한다고 가정합니다.

내 솔루션은 이러한 수집 작업을 제쳐두고 조절 된 속도로 일괄 처리하여 단일 상태 변경으로 ~ 800 개의 문서를 추가 할 수있는 특수 미들웨어를 만드는 것이 었습니다. 성능 문제를 해결했지만 이벤트 순서를 변경하면 일관성없는 상태로 이어질 수 있으므로 본질적으로 위험합니다. 예를 들어, 모든 문서가 Redux 상태에 추가되기 전에 구독이 준비로 표시되지 않도록 구독 상태 작업이 동일한 스로틀 러를 통해 전달되었는지 확인해야했습니다.

@ jedwards1211 비슷한 문제가 있습니다 (초기 데이터를 구성하는 많은 작은 메시지).

일괄 업데이트를 수행하여 동일한 방식으로 해결되었습니다. 미들웨어 대신 (작은) 사용자 지정 대기열 메커니즘을 사용했습니다 (배열의 모든 업데이트를 푸시하고 업데이트 할 항목이 있으면 정기적으로 모든 업데이트를 동시에 업데이트합니다.

@andreieftimie 예, 플롯 끌기 및 확대 / 축소와 같이 즉각적인 업데이트가 필요한 UI 상호 작용이 있기 때문에 내 앱에서 더 까다 롭습니다. 따라서 액션을 즉시 발송할지 아니면 일괄 발송을 위해 대기열에 넣을지 결정하는 미들웨어 계층이 있어야합니다.

그만한 가치가 있기 때문에 나는 "가지"를 만드는 아이디어가 있었다. 그것은 단일 상점 원칙을 완전히 무시하지만 좋은 타협처럼 보였습니다.

https://github.com/stephenbunch/redux-branch

@ jedwards1211 앱이 복잡 해짐에 따라 결국 특정 유형의 데이터와 특정 유형의 업데이트를 분리하여 특정 저장소가 전체 부하를 처리하지 못하도록해야한다고 생각합니다.

백엔드와 동기화하려는 핵심 상태가 있고, 현재 수행중인 작업에 따라 앱 UI 구성 요소가 올바르게 표시되도록 일부 애니메이션 상태가 있으며, 추적중인 디버그 데이터가있을 수 있습니다. 갈라져.

이 인위적인 예제에서는 확실히 단일 Redux 스토어에서이 모든 것을 구축 할 수 있지만 어떻게 설계 하느냐에 따라 상태 트리의 다양한 분기에 대한 우려 사이에 모호한 경계가있을 수 있으며 명확성이 부족할 수 있습니다. 주어진 행동이 어떤 상태와 상호 작용할 것인지에 관한 것입니다.

상태의 범위를 지정하려는 방법과 그에서 기대하는 성능 특성에 따라 다른 상태 관리 전략을 사용하는 것이 완벽하게 합리적이라고 생각합니다. Redux는 작업을 롤백 또는 재생하거나 직렬화하고 나중에 다시 돌아갈 수있는 상태에 적합합니다. 애니메이션 상태의 경우 원하는 경우 변경 가능한 저장소 또는 반응 저장소를 사용할 수 있습니다. 그렇게하면 오버 헤드가 줄어들고이 일시적 (그러나 여전히 필요한) 상호 작용 상태로 애플리케이션 상태를 오염시키지 않을 것입니다.

정말 빨리, 곧 출시 될 React 파이버 아키텍처를 사용하여 요점을 만들고 싶습니다. 여기에 링크 가 있습니다. 제 이해가 약간 오래된 경우 사과드립니다. 대략 파이버 아키텍처는 React 구성 요소 트리를 통해 전파되는 다양한 종류의 업데이트가 있으며 이러한 업데이트가 수행되는시기와 방법에 대한 다른 기대가 있음을 인식합니다. 애니메이션 업데이트가 빠르고 반응이 빠르고 안정적이기를 원하고, 큰 상호 작용 업데이트로 인해 애니메이션에 버벅 거림이 발생하는 것을 원하지 않습니다.

따라서 파이버 아키텍처는 업데이트를 작업 패킷으로 나누고 수행중인 작업에 따라 우선 순위에 따라 업데이트를 예약합니다. 애니메이션은 중단되지 않도록 우선 순위가 높으며 느린 기계적 업데이트는 우선 순위가 낮습니다.

React 파이버에 대한 많은 세부 정보를 건너 뛰고 프로세스에서 몇 가지 잘못된 점을 발견했지만 제 요점은 이것이 다양한 유형의 데이터를 사용하는 데이터 저장소에 필요하다고 생각하는 세분화 된 접근 방식이라는 것입니다.

오늘 복잡한 앱을 구축하고 있다면 몇 개의 다른 스토어에서 지원하는 Redux와 같은 최상위 스토어 클래스부터 시작하겠습니다. 대충:

• 최상위 데이터 저장소에는 들어오는 작업에 대한 대기열이 있습니다.
• 작업은 빠르게 전달되어야하는 애니메이션 작업 또는 우선 순위가 낮은 응용 프로그램 상호 작용을위한 것입니다.
• 대기열의 애니메이션 작업은 requestAnimationFrame 루프에서 관찰 가능한 백엔드로 전달됩니다.
• 대기열의 애니메이션 작업이 완료되면 상호 작용 작업이 redux로 전달됩니다.

이 이야기는 Redux를 기반으로 한 완전한 상태 솔루션에 매우 가깝습니다. Redux는 일련의 작업 후에 보려는 데이터에 적합하며 신중한 처리가 필요한 다른 상태도 많이 있습니다.

@jsonnull 저는 상점에 애니메이션 상태를 저장할 필요가 없었습니다. 로컬 상태는 항상 애니메이션 사용 사례에 이상적이었습니다. 로컬 애니메이션 상태가 완전히 적합하지 않은 사용 사례가 있는지 궁금합니다. 그래도 새로운 아키텍처에 대한 훌륭한 아이디어가있는 것 같습니다.

@ jedwards1211 로컬 애니메이션 상태가 작동하지 않는 몇 가지 경우가 있습니다. 나는 당신에게 허락 할 것입니다. 그들은 당신이 모든 응용 프로그램에서 마주 치는 경우는 아니지만 충분히 자주 등장한다고 생각합니다.

한 경우에는 로컬 상태가없는 Redux 이외의 라이브러리를 사용하고 있습니다. (좋아, 예, 제가 여기서 약간 속임수를 쓰고 있다는 것을 알고 있습니다.) 매우 간결한 하이퍼 스크립트 접근 방식을 사용하고 가상 돔, 순수 기능 구성 요소를 사용하는 경우 로컬 상태 대신 일부 애니메이션을 전달해야합니다. 루트 노드 또는 다시 렌더링하는 노드에 상태를 지정합니다.

이 경우 몇 가지 애니메이션 세부 정보가 설정된 상태 트리를 사용하면 로컬 상태 부족 문제를 해결할 수 있으므로 애니메이션을 트리거하고 애니메이션을 일정 기간 동안 실행하는 등의 작업을 수행 할 수 있습니다.

여기서 중요한 점은 이러한 애니메이션을 수행하는 두 가지 방법이 있다는 것입니다. 렌더링의 일부로 수행하고 "상태 함수로서의 UI"메타포를 그대로 유지하거나 DOM을 개별적으로 변경하는 것입니다. 거의 항상 더 나은 대답은 변경하는 대신 다시 렌더링하는 것입니다.

이제 일부 애니메이션 상태를 로컬로 유지할 수있는 기능이있는 예를 살펴 보겠습니다. 그 위에 React 기반 UI가있는 브라우저 게임을 빌드합니다.

• 일반적으로 틱을 사용하여 게임을 구동합니다. 게임 시간은 0에서 시작하여 매 프레임마다 증가합니다. 코어 게임 애니메이션은 캔버스 또는 로컬 상태가없는 WebGL에서 수행 될 수 있으므로 이러한 틱을 기반으로 애니메이션 시작 시간과 진행률을 기준으로합니다.

예 : 스프라이트 캐릭터는 10 개의 프레임으로 구성된 애니메이션을 가지고 있으며 400ms 이상 애니메이션을 재생하려고하므로 2 틱 정도마다 그려지는 스프라이트를 변경해야합니다.

더 높은 해상도를 원한다면 틱이 타임 스탬프가 될 수도 있습니다.

• 게임이 일시 중지 될 수도 있습니다.이 경우 React UI 측에서 수행 된 일부 애니메이션을 중지 할 수 있습니다.

이 게임 예제에서는 tick 액션의 일부로 틱을 증가시키는 것을 원하지 않습니다. 대신 관찰 가능한 구조에서 틱을 개별적으로 증가 시키려고합니다. 그리고 키보드 캐릭터 이동이나 공격과 같은 Redux 액션을 디스패치하면 현재 틱 또는 현재 시간을 그들에게 전달하여 어떤 틱에서 액션이 발생했는지 기록 할 수 있고 UI 구성 요소는 애니메이션이 시작된 시간을 로컬로 기록 할 수 있습니다. .

이제 전역 애니메이션 상태를 상호 작용 상태에서 분리했습니다. Redux 상태 만 사용하거나 작업을 재생하여 "재생"을 수행하려는 경우 상태의 일부로 틱을 증가시키는 데 부담을주지 않습니다. 나무.

일반적으로 Redux를 통해 시작 / 중지 시간을 전달하고 구성 요소가 나머지 상태를 로컬로 유지하도록하여 애니메이션을 조정하는 것이 훨씬 좋습니다.

이것은 게임에만 적용되는 것이 아닙니다. React를 사용하여 사이트에서 일련의 장기 실행 애니메이션을 수행하려는 경우와 같이 확장 된 애니메이션 시퀀스가이를 통과 할 수 있습니다.

@jsonnull 멋지네요 , 좋은 예입니다. 공유해 주셔서 감사합니다.

저는 간단히 말하고 싶습니다-Redux에서는 서로에 대한 링크가있는 상태 객체를 저장할 수 없습니다. 예를 들어-사용자는 많은 게시물을 가질 수 있고 게시물은 많은 댓글을 가질 수 있으며 이러한 객체를 방식으로 저장하고 싶습니다.

var user = {id: 'user1', posts: [], comments: []}
var post = {id: 'post1', user: user, comments: []}
user.posts.push(post);
var comment = {id: 'comment1', post: post, user: user}
post.coments.push(comment)
user.comments.push(comment)
appState.user = user

Redux는 순환 참조가있는 객체 계층의 사용을 허용하지 않습니다. Mobx (또는 Cellx)에서는 단순히 객체와 함께 일대 다 및 다 대다 참조를 가질 수 있으며 비즈니스 로직을 여러 번 단순화했습니다.

@bgnorlov 나는 아무것도 생각하지 않는다 redux 당신에 대해 얘기처럼 패키지를 순환 참조를 금지합니다 - 그들은 단지 더 어려워 복제 할 수 있도록 state 당신의 감속기에 있습니다. 또한 확실하지는 않지만 Immutable.js를 사용하여 상태를 나타내는 경우 순환 참조로 상태를 변경하는 것이 더 쉬울 수 있습니다.

외래 키를 사용하여 redux 상태의 관계를 모델링 할 수도 있지만 ORM과 유사한 객체 참조를 사용하는 것만 큼 편리하지 않다는 것을 이해합니다.

var user = {id: 'user1', postIds: [], commentIds: []}
var post = {id: 'post1', userId: user.id, commentIds: []}
user.postIds.push(post.id);
var comment = {id: 'comment1', postId: post.id, userId: user.id}
post.commentIds.push(comment.id)
user.commentIds.push(comment.id)
appState.userId = user.id
appState.posts = {[post.id]: post}
appState.comments = {[comment.id]: comment}

// then join things like so:
var postsWithComments = _.map(appState.posts, post => ({
  ...post,
  comments: post.commentIds.map(id => appState.comments[id]),
})

@ jedwards1211 을 사용하여 redux에서 순환 참조를 사용하여 상태를 복제하려면 감속기가 변경 사항에 영향을받은 객체의 모든 새 복사본을 반환해야합니다. 개체에 대한 참조가 변경되면 관련 개체도 새 복사본이어야하며 이는 반복적 인 방식으로 반복되며 모든 변경에 대해 완전히 새로운 상태를 생성합니다. Immutable.js는 순환 참조를 저장할 수 없습니다.
일부 이벤트 핸들러가 일부 데이터를 필요로 할 때 정규화 접근 방식을 사용하면 전역 상태에서 ID로 개체를 가져올 때마다 필요합니다. 예를 들어-이벤트 핸들러 어딘가에서 작업 형제를 필터링해야합니다 (작업은 계층 구조를 가질 수 있음). redux를 사용하면 앱 상태에 액세스하기 위해 썽크를 발송해야합니다.

var prevTask = dispatch((_, getState)=>getState().tables.tasks[task.parentId]).children.map(childId=>dispatch((_, getState)=>getState().tables.tasks[childId])).filter(task=>...) [0]

또는 선택자와 함께

var prevTask = dispatch(getTaskById(task.parentId)).children.map(childId=>dispatch(getTaskById(childId)).filter(task=>...)[0]

이 상용구는 코드를 mobx 버전과 비교하여 엉망으로 만듭니다.

var prevTask = task.parent.children.filter(task=>...)[0]

@ jedwards1211 , @bgnorlov : FWIW, 이것이 제가 Redux-ORM을 좋아하는 이유 중 하나입니다. 이를 통해 Redux 스토어를 정규화 할 수 있지만 관계형 업데이트 및 조회를 더 간단하게 수행 할 수 있습니다. 실제로 마지막 예제는 기본적으로 Redux-ORM과 동일합니다.

방금 Redux-ORM 기본 사항 과 핵심 개념 및 고급 사용법을 설명하는 몇 개의 블로그 게시물을 작성했습니다.

@markerikson 멋지다, 팁 주셔서 감사합니다!

@gaearon

한 가지 주목할 점은 Redux가 모든 상태에 사용되도록 의도하지 않는다는 것입니다. 앱에 중요해 보이는 모든 것. 입력과 애니메이션 상태는 React (또는 다른 임시 상태 추상화)에서 처리해야한다고 주장합니다. Redux는 가져온 데이터 및 로컬에서 수정 된 모델과 같은 작업에 더 적합합니다.

이 의견이 매우 유용하다는 것을 알았습니다. 내가 파티에 늦었다는 건 알지만 그게 내 요점의 일부일지도 몰라 그 댓글이 게시 된 지 1 년이 넘었고이 아이디어가 표현 된 유일한 곳은 이곳뿐입니다.

각도가 있고 확실하게 비 플럭스 / 리덕스 배경에서 나온 아이디어를 스스로 공식화하는 것은 매우 어렵습니다. 특히 많은 예제가 여전히 텍스트 상자의 모든 키업에 대한 작업을 생성 할 때. 누군가가 모든 Redux 문서 페이지의 상단에 50px 텍스트로 그 인용문을 넣기를 바랍니다.

@leff 동의합니다. 나는 그 정확한 아이디어를 얼마 전에 합성했지만 충분히 언급되지 않았습니다. 기록 관리에 Redux를 사용하더라도 Redux 스타일의 상태 관리에 부담을주지 않아도되는 많은 임시 상태가있는 경우가 많습니다.

작업 할 기회를 가졌던 사람들, 예를 들어 풍부한 실행 취소 / 다시 실행을 수행하는 성숙한 데스크탑 앱에게 반드시 놀라운 일은 아닙니다. 그러나 Redux를 통해 이러한 아이디어를 얻는 새로운 이민자들의 바다에는 계시가 될 것입니다.

@bgnorlov 는 Immutable.js로 순환 참조를 저장하는 것이 불가능하다는 좋은 점입니다. 그래도 좋은 기능이라고 생각합니다.

요즘에는 컨텍스트 외부에서 사용하지 않는 일시적인 뷰 특정 상태 (예 : redux-form 인스턴스의 상태) 인 경우에도 거의 모든 것을 Redux에 저장하는 경향이 있습니다. 대부분의 경우 문제없이 이러한 상태를 redux에서 옮길 수 있습니다. 그러나 장점은 미래에 대응하기 위해 외부 구성 요소가 필요할 경우에 대비한다는 것입니다. 예를 들어, 양식에 오류가 있거나 제출 중일 때 변경되는 탐색 모음에 아이콘이있을 수 있습니다.

명심해야 할 가장 중요한 점은 모든 정규화 된 상태를 Redux에 넣는 것 (즉 뷰를 렌더링하기 위해 함께 결합해야하는 모든 것)이 사용하기 가장 쉽다는 것입니다. 어떤 것과도 결합 할 필요가없는 상태는 아마도 당신에게 어려움을주지 않고 Redux 외부에서 살 수 있지만, 보통 Redux에 넣는 것도 아프지 않습니다.

FWIW, 문서는 http://redux.js.org/docs/faq/OrganizingState.html#organizing -state-only-redux-state에 따라 모든 것이 Redux로 이동해야하는 것은 아니라고 지적합니다.

Redux가 "적절한"것에 대해 최근 온라인에서 꽤 많은 대화가있었습니다. 어떤 사람들은 말 그대로 모든 것을 Redux에 넣는 것의 이점을보고, 다른 사람들은 너무 번거롭고 서버에서 검색된 데이터 만 저장하고 싶어한다고 생각합니다. 따라서 여기에는 고정 된 규칙이 없습니다.

항상 그렇듯이 사람들이 문서 개선에 대한 아이디어를 가지고 있다면 PR을 전적으로 환영합니다. :)

리듀서를 재사용해야하고 redux 상태에서 "하위 상태"를 할당 할 수 있어야한다면 쉽게 할 수있는 플러그인을 개발했습니다 (React 통합 포함).

https://github.com/eloytoro/react-redux-uuid

@eloytoro IMO 상태에서 하드 코딩 된 작업 유형이나 위치가있는 일부 타사 감속기에 문제가있는 경우 프로젝트에서 문제를 열어야합니다. 크리에이터 패턴.

@eloytoro 그런 식으로 쓰려고 했어요. 참고 해주셔서 대단히 감사합니다!

@ jedwards1211 나는 당신이 잘못된 생각을 가지고 있다고 생각합니다. 제 3 자 리듀서 나 그 문제에 대해 언급 한 적은 없지만, 내 스 니펫이 리듀서를 동적 크기의 컬렉션에서 재사용 가능하게 만드는 문제를 어떻게 해결할 수 있는지 보여 주려고합니다.

@avesus 가 당신을 위해 일하기를 바랍니다.

@eloytoro 아, 더 의미가 있습니다.

작년에 저는 Redux를 사용하여 상당히 복잡한 게임을 만들었습니다. 또한 Redux를 사용하지 않는 다른 프로젝트에 참여했습니다. 대신 모든 것을 UI 저장소와 서버 저장소 (입력 포함)로 분리하는 사용자 정의 구축 된 최소한의 프레임 워크에 참여했습니다. 너무 많은 세부 사항을 다루지 않고 지금까지 내 결론은 다음과 같습니다.

단일 상태가 항상 더 좋지만 과도하게하지 마십시오. 모든 keyDown ()을 저장소를 통해 다시보기로 가져 오는 것은 혼란스럽고 불필요합니다. 따라서 일시적인 상태는 로컬 구성 요소 상태 (예 : React 's)에 의해 처리되어야합니다.

나는 redux와 반응이 관찰 가능한 웹에 불을 붙 였기 때문에 페이지에서 좋은 애니메이션의 양이 감소했다고 생각합니다.

@ mib32 당신이