데이터 변경 코드를 함수에 넣어야 할까요, 아니면 액션에만 넣어야 할까요?

Question

현재 객체 유형을 사용하여 시간표 "문서"를 모델링하는 버스 시간표 애플리케이션을 작성 중입니다.

으아아아

타입 외에도 많은 기능이 있는데, 돌연변이를 사용할 경우에는 주로 클래스에서 메소드로 작성합니다. 저는 주로 Immer를 사용하므로 확장된 구문을 많이 작성할 필요가 없습니다. 예를 들어

으아아아

상태를 관리하기 위해 Zustand와 Immer를 사용하지만 Redux를 사용해도 문제는 동일할 것 같습니다. 내 상점에는 Timetable 개체 배열과 Immer를 사용하여 현재 선택한 Timetable 개체를 다시 할당하는 작업이 있습니다.

으아아아

그런 다음 React 구성 요소에서 데이터 변경 함수를 호출하고 업데이트 작업을 호출합니다.

으아아아

이 방법은 작동하지만 올바르게 수행하고 있는지 잘 모르겠습니다. 이제 Immer 호출의 두 레이어가 있고, 내 구성 요소에는 이제 이벤트 핸들러에서 직접 호출되는 데이터 수정 함수가 있으며, 전체적으로 사소한 버그임에도 불구하고 "메서드"의 모양이 별로 마음에 들지 않습니다.

내가 고려한 사항:

• 모든 데이터 수정 사항을 작업으로 전환하세요. 저장소의 개체 배열을 인덱싱하는 데 중복이 많기 때문에 유지 관리가 더 어렵고 이해하기가 더 어려워 보입니다.
• 각 데이터 수정 기능에 대한 작업을 만든 다음 내 이벤트 핸들러에서 이러한 작업을 호출합니다. 이는 이름 측면에서도 일부 중복을 생성하는 것 같습니다.
• 나의 Timetable 类型转换为一个类，将数据修改函数重写为变异方法，并设置 [immerable] = true를 배치하고 Immer가 내 작업에 대한 모든 작업을 수행하도록 하세요. 저는 이렇게 했지만 불변 기록 모드를 고수하고 싶습니다.

Flux, Zustand 또는 Immer에 대한 문서는 첫 번째 옵션을 표시하는 경향이 있으며 가끔씩만 counter = counter + 1만큼 간단한 응용 프로그램은 없습니다. Flux 아키텍처를 사용하여 애플리케이션을 구축하는 가장 좋은 방법은 무엇입니까?

Answer 1

(저는 Zusand 및 Immer에 익숙하지 않지만 도움을 드릴 수 있을 것 같습니다...)

항상 다양한 방법이 있는데 여기서는 제가 가장 좋아하는 방법을 제안해보겠습니다.

"scheduling" 동작과 실제 상태 "mutation"을 명확하게 구분하세요. (어쩌면사이에 다른 레벨을 추가할 수도 있습니다).

특정 “돌연변이” 기능

일반적인 기능보다는 특정 "돌연변이" 기능을 만드는 것이 좋습니다. 예:

• 대신 updateThisTt：() => { ...,
• addStop: () => { ...와 같은 기능을 사용하세요.

각각 목적이 있는 돌연변이 함수를 필요한 만큼 많이 만드세요.

"돌연변이" 기능으로 새로운 상태를 구축하세요

개념적으로는 돌연변이 함수 내에서 immer 생성기만 사용하세요.
(상점에 관한 것입니다. 물론 immer를 다른 용도로 사용할 수 있습니다.) .

이 공식 예 기준:

으아아아

이제 구성요소 내에서 "돌연변이자" 기능을 호출할 수 있습니다.

으아아아

새로운 나라 건설

새 상태 구축이 복잡해지는 경우에도 일부 "빌더" 기능을 추출할 수 있습니다. 하지만 먼저 다음 섹션인 "대용량 파일 및 복제"를 고려하십시오.

예를 들어 addStop 함수는 Zustand 돌연변이 내에서 호출될 수도 있습니다:

으아아아

대용량 파일 및 중복

코드 중복은 반드시 피해야 하지만 항상 절충안이 있습니다.

구체적인 접근 방식을 제안하지는 않겠지만, 코드는 종종 작성된 것보다 읽는 것이 더 많다는 점에 유의하세요. 때때로 state.timetables[index] 같은 글자를 몇 번 더 쓰는 게 좋을 것 같아요. 코드의 목적을 더욱 분명하게 만드는 경우. 스스로 판단해야합니다.

어쨌든 다른 작업을 수행하지 않는 별도의 파일에 Mutation 기능을 넣는 것이 좋습니다. 이렇게 보면 생각보다 이해하기 쉬울 수도 있습니다.

매우 큰 파일이 있지만 상태 수정에만 전적으로 집중하고 있는 경우, 그리고 구조가 일관되어 스크롤을 내려도 쉽게 읽을 수 있습니다. 몇 페이지.

예를 들어 다음과 같은 경우:

으아아아

또한 이러한 가변 함수는 완전히 독립적이라는 점에 유의하세요 (아니면 그럴까요? Zustand가 여기서 순수 함수를 사용했으면 좋았을 텐데요, 그렇죠?) .

복잡해지면 여러 돌연변이 기능을 분할할 수도 있다는 의미입니다. 폴더 내에서 별도의 파일로 분할 /store/mutators/timeTable.js처럼요.

하지만 나중에 언제든지 쉽게 할 수 있습니다.

"페이로드"("액션 호출자") 구축

다른 "레벨"이 필요하다고 느낄 수도 있습니다. 이벤트 핸들러와 mutator 사이. 보통 이런 레이어가 있는데, 적절한 이름이 없습니다. 이것을 일시적으로 "Operation Caller"라고 부르겠습니다.

때때로 무엇이 "배리오그램"이고 무엇이 "배리오그램"인지 결정하기 어려울 때가 있습니다 "액션 호출자".

어쨌든 "액션 호출자" 내부에 "일부 데이터를 구축"할 수 있지만 여기에서는 어떤 종류의 상태 조작도 이루어지지 않습니다. 심지어 immer에서도 마찬가지입니다.

상태 변환 및 페이로드 생성

이것은 미묘한 차이이므로 너무 걱정하지 않아도 됩니다 (예외가 있을 수 있음) . 하지만 예를 들면 다음과 같습니다.

당신은 "액션 호출자" 내에서 이전 상태의 일부를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

으아악

그러나 이전 상태를 새 상태로 매핑(또는 변환)해서는 안 않습니다. 예: 으아악 또 다른 예

여기에는 구체적인 제안이 없습니다. 예를 들면 다음과 같습니다.

뮤테이터에 많은 값을 전달하면 혼란스러울 수 있습니다. 예:

으아악

이벤트 핸들러에서는 "새 항목 추가"와 같이 실제로 하고 싶은 작업에 집중하고 싶습니다. 그러나 모든 주장을 고려하지는 마십시오. 또한 다른 용도로 새 항목이 필요할 수도 있습니다.

또는 다음과 같이 쓸 수도 있습니다:

으아악