반응의 무대에서 계산과 데이터 조정을하는 것은 나쁜 습관입니까?

Question

POLL 작업에서 매 10 초마다 한 번씩 실행되는 사가가있어 GUI에서 현재 상태를 업데이트했습니다.

POLL이 발생할 때 나머지 인터페이스를 걸어 몇 가지 호출을해야만 신경 써야 할 구성 요소를 찾을 수 있습니다. 총 1 ~ 5 개의 구성 요소가 있습니다. 각 구성 요소의 Foo 및 Bar 요소에 대해 별도의 나머지 호출을해야합니다.

그런 다음 몇 가지 합계를 수행해야합니다. Foo와 Bar 데이터를 함께 사용하여 구성 요소를 나열하기 위해 테이블을 예상하고, 대시 보드의 모든 구성 요소에서 일부 합계를 계산합니다. cpu는 집중적으로 사용하지만, 너무 많은 것들을 필요로하기 때문에 적절한 코드를 추가합니다.

현재 저는 사가에서이 모든 작업을 수행하고 있습니다. 그러나 이것이 나쁜 실행으로 간주되는지 확실하지 않습니다. 나는 감속기가 데이터 조정을위한 일반적인 '이동'장소 인 것처럼 느껴지지만, 대용량의 페이로드로 모든 행동을 던지는 것은 기분이 이상합니다. 대부분의 나머지 응답은 데이터가 아닙니다. 신경 쓰지 마. 나는 또한 사가에서 모든 처리를하는 것을 좋아한다. 그래서 나는 모든 일의 끝에서 오류를 사용자에게 보여 주거나 이전의 오류를 제거하는 성공 동작을 전달하기 위해 오류 동작을 전달할 것을 결정할 수있다. 작업을 지우려면 데이터 처리가 더 많이 필요합니다.

내 관심사는 처리기를 처리하기 위해 사가 클래스에서 조금 벗어난 느낌을주는 많은 도우미 메서드로 생성기가 다소 커지고 있다는 것입니다. (내가 필요로 할 때 유틸리티 클래스로 옮길 필요가 있습니다. 생각한다). 프로세싱은 너무 비싸지 않으며 생성기를 사용하고 있습니다. 그래서 프로세싱이 사가의 '스레딩'에 눈에 띄는 영향을 미칠 것이라고 생각하지 않습니다. 그래도 추천 된 모범 사례가 있다면 저는 그것에 충실하고 싶습니다. 내 사가에서 데이터를 수정 한 모든 표준 작업을 중단하고 다른 처리없이 국가에 저장하기 위해 형식 지정 객체를 감속기에 보냈습니까?

Answer 1

이것은 실제로 Redux FAQ on "where should my business logic live?"에 의해 해결되는 일반적인 질문의 특정 사례입니다. 그 대답을 인용 :

지금 문제는 행동 창조자에게 무엇을 넣어야하고 감속기에서 뚱뚱한 행동 객체와 얇은 행동 객체 사이의 선택입니까? 액션 생성자에 모든 로직을 넣으면 기본적으로 업데이트 상태를 선언하는 뚱뚱한 액션 객체로 끝납니다. 리 듀서는 순수하고, 멍청하고, 추가가되고, 제거하고, 이러한 기능을 업데이트합니다. 그들은 쉽게 구성 할 수 있습니다. 그러나 귀하의 비즈니스 로직은 그리 많지 않습니다. 감속기에 더 많은 로직을 넣으면 멋지고 얇은 액션 객체로 끝나고 대부분의 데이터 논리는 한 곳에서 처리되지만 감속기는 다른 브랜치의 정보가 필요할 수 있기 때문에 작성하기가 어렵습니다. 당신은 큰 감속기 또는 감속기로 끝나고 더 높은 국가로부터의 추가적인 논증을 취합니다.

이 많은 작업 형식의 데이터를 준비하고 수행 (IT 구성 요소, 썽크, 무용담, 또는 미들웨어이든) "작업 생성"측에 논리를 가지고 아무 문제가 없다, 단순히 감속기를 가진 행동에 포함 된 것을 저장하십시오. 반대로 리듀서 측면에서 더 많은 로직을 사용하면 시간 이동 디버깅이 실제 코드를 다시 실행하여 동작을 편집하고 다시 시도 할 수있는 기회를 얻게됩니다.

전반적으로 당신이하는 일은 완벽하게 합리적이라고 들었습니다.