텍스트 편집기 용 Redux 아키텍처 : 결합 상태 처리

Question

텍스트 편집기와 비슷한 방식으로 React/Redux를 사용하여 응용 프로그램을 작성하고 있습니다. 그것은 텍스트 편집기가 아니지만 동일한 일반적인 패러다임입니다. 새 항목을 배치하기위한 커서가 있습니다. 항목을 추가, 선택, 삭제할 수 있습니다.

나는 redux의 정신을 유지하는 방식으로 내 감속기를 구조화하는 가장 좋은 방법을 고민하고 있습니다. 선택 상태, 텍스트 자체, 커서 상태 및 기타 설정을 나타내는 별도의 상태 슬라이스가 있습니다. 나는 "희박한"접근법이 각각의 상태 조각에 대해 감속기를 가지고 행동에 대한 반응으로 상태를 독립적으로 변형시키는 것이라고 생각합니다.

그러나 텍스트 편집기에서 이러한 상태 조각은 언뜻보기에 훨씬 더 결합되어 있습니다. 키를 누르면 커서 위치에 문자가 추가되고 커서가 앞으로 이동합니다. 그러나 텍스트를 선택하면 선택한 텍스트가 먼저 삭제됩니다. "삽입"모드에 있으면 오른쪽 텍스트가 "사용"됩니다. 또는 수정 자 키가 눌려져 있고 텍스트가 전혀 추가되지 않았을 수 있습니다.

즉, 서로 다른 상태 조각은 매우 결합되어 있으며 한 상태에서 발생하는 상황은 다른 상태의 상태에 따라 달라집니다.

을 읽었으며 슬라이스 감속기간에 상태를 공유하는 방법을 알고 있지만 최종 결과가 모든 슬라이스 감속기에 전체 상태를 전달하는 경우에는보기에 좋지 않습니다. 내가 그의 접근 방식에 대해 싫어하는 또 다른 점은 각 감속가가 전반적인 상태를 살펴보고 특정 행동에 대한 올바른 응답이 무엇인지에 대해 독립적으로 동일한 결론에 도달해야한다는 것입니다. 그것이 내가해야 할 일입니까, 아니면 어떻게 든 나의 상태를 어떻게 다르게 구성해야합니까?

커서, 선택 상태, 내용 등을 알려주는 하나의 중앙 집중식 감속기 대신 개념적으로 쉽게 변형 할 수 있지만 확장 성이 좋지는 않습니다.

I've also read that many times coupled state is a sign that your state isn't minimal 그리고 메모를 작성한 셀렉터를 재구성하고 사용해야합니다. 그러나 그것은 여기에있는 것처럼 보이지 않습니다. 커서의 위치는 텍스트에서 파생 될 수 없으며 선택 상태도 아닙니다.

마지막으로 필자는 Thunk middleware를 여러 가지/복잡한 작업을 처리 할 때 제안한 것으로 보았습니다. 비동기 파견을 위해 더 많은 의미가있는 것처럼 보이기 때문에 나는 주저합니다.

"redux"디자인 패턴과 가장 잘 맞는이 유형의 앱을 디자인하는 올바른 방법을 이해하고 앞으로 여러 가지 방법이있을 경우 발생할 수있는 모든 상충 관계를 이해하고 싶습니다.

Answer 1

내가 "Structuring Reducers" 문서 섹션, 너무 좋은 적어도 그것을 읽고 도움을 찾는 : 사람들이 있는지 썼다

당신은 돌아 오는 감속기 로직에 대한 관용적 의도 된 접근 방식은 소형 감속기 기능입니다 맞아, 상태 조각에 의해 조직되어 독립적으로 동일한 작업에 응답합니다. 그러나 이는 고정 된 요구 사항 인이 아니며 일부 논리를 한 곳으로 통합하는 것이 더 바람직합니다.

귀하의 주 구조가 무엇인지 정확히 파악하지 못하면 절대 구체적인 조언을 제공하기가 약간 어렵지만 전반적으로 어떤 방식 으로든 주 및 감속 논리를 자유롭게 구조화해야합니다. 귀하의 응용 프로그램에 대한 가장 좋은 의미는 입니다. 한 번에 여러 중첩 된 조각을 업데이트하는 좀 더 중앙화 된 감속기 기능에 그러한 논리 중 일부를 사용하는 것이 더 효과적이라면 그걸로 가십시오! 몇 가지 다른 관찰로

다음 Redux FAQ question on "sharing state across reducers" 당

, 하나의 접근 방식은 파견 활동에 더 많은 정보를 넣어하는 것입니다. 예를 들어, {type : "KEYSTROKE", key : "A"}을 파견하는 대신 {type : "KEYSTROKE", key : "A", cursorPos : 12345, ctrl : true, alt : false}을 파견 할 수 있습니다.

또한 썽크는 기본 비동기 로직에 적합한 장소이지만 현재의 앱 상태를 검사하는 것을 포함하여 복잡한 동기 논리에도 유용합니다. 나는 a gist that demonstrates some common thunk use cases입니다.

맞쳐 이 당신에게 일반적으로 도움이 될 수있는 몇 가지 더 많은 자원을 던져 :

• 내 React/Redux links listwriting reducers
• 내 "Practical Redux" tutorial series에 문서를 연결하는 부분은 감속기 구조에 대한 몇 가지 변화를 보여줍니다있다 (게시물 Practical Redux, Part 7: Form Change Handling, Data Editing, and Feature Reducers 포함).

은 (사이드 참고로, 나는 또한 현재 돌아 오는이 요구하는 기술 실제 어떤 제한 논의가 블로그 게시물에 노력하고 이유를 대 당신이 을 얼마나 돌아 오는을 사용하는 "를위한"대 그것의 방법에있어 가능 Redux를 사용합니다. 끝내려면 시간이 좀 걸리지 만 관심이 있다면 내 블로그를 주시하십시오.)

마지막으로 더 자세히 논의하고 싶다면 Reactiflux 채팅 채널 Discord에서 놀고, 질문하고 배울 수있는 좋은 장소입니다. 초대 링크는 https://www.reactiflux.com입니다. 언제든지 거기에 들러서 질문 해보십시오. 저는 보통 저녁 시간대에 미국 시간에 있지만, 항상 사람들이 즐거운 시간을 가지기를 바라고 있습니다.

Answer 2

큰 일을하고있는 것 같습니다. 아마도 이미 알고있을 것입니다. 그러나 처음부터 텍스트 편집기를 만드는 것은 쉬운 일이 아닙니다.

기존 소프트웨어를 사용하여 평가 했습니까?

최근에 저는 매우 강력한 Codemirror을 성공으로 사용하여 React.js 응용 프로그램과 통합했습니다. Codemirror는 이미 문서 상태에 대한 개념을 훌륭한 방식으로 관리합니다.

환경에 반응이 콜백 및 이벤트를 통해 문서에 첨부 :

• Codemirror 인스턴스가 완전히 (문서 AKA) 에디터를 관리 : 의미

  .

Codemirror가 사용자의 필요에 맞지 않는 경우 코드와 internals 설명을 확인하십시오.