Redux: API 호출을 올바른 위치에 배치하려고합니다.

이것은 거의 맞지만 문제는 _ 순수한 액션 제작자를 불러서 일이 일어날 것이라고 기대할 수 없다는 것입니다. 액션 생성자는 _what_이 발송되어야 함을 지정하는 함수일뿐임을 잊지 마십시오.

// CounterActions
export function increment() {
  return { type: INCREMENT }
}


// Some other file
import { increment } from './CounterActions';
store.dispatch(increment()); <--- This will work assuming you have a reference to the Store
increment(); <---- THIS DOESN'T DO ANYTHING! You're just calling your function and ignoring result.


// SomeComponent
import { increment } from './CounterActions';

@connect(state => state.counter) // will inject store's dispatch into props
class SomeComponent {
  render() {
    return <OtherComponent {...bindActionCreators(CounterActions, this.props.dispatch)} />
  }
}


// OtherComponent
class OtherComponent {
  handleClick() {
    // this is correct:
    this.props.increment(); // <---- it was bound to dispatch in SomeComponent

    // THIS DOESN'T DO ANYTHING:
    CounterActions.increment(); // <---- it's just your functions as is! it's not bound to the Store.
  }
}

이제 예를 들어 보겠습니다. 가장 먼저 명확히하고 싶은 것은 비동기식 dispatch => {} 양식이 필요하지 않다는 것입니다. 단 하나의 작업을 동 기적으로 전달하고 부작용이없는 경우 ( loginError 및 loginRequest 경우 true)

이:

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return dispatch => {
    dispatch({ error, type: LOGGED_FAILED });
  };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return dispatch => {
    dispatch({ user, type: LOGIN_ATTEMPT });
  };
}

다음과 같이 단순화 할 수 있습니다.

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

// You'll have a side effect here so (dispatch) => {} form is a good idea
export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    // router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

둘째, 감속기는 _ 부작용이없는 순수한 기능 _이어야합니다. 감속기에서 API를 호출하지 마십시오.

이:

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
}).asMutable(); // <---------------------- why asMutable?

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      console.log(action.user);
      LoginApiCall.login(action.user); // <------------------------ no side effects in reducers! :-(
      return state;
    case LOGGED_FAILED:
      console.log('failed from reducer');
      return state;
    case LOGGED_SUCCESSFULLY:
      console.log('success', action);
      console.log('success from reducer');
      break;
    default:
      return state;
  }

아마도 더 비슷하게 보일 것입니다

const initialState = new Immutable.Map({
  email: '',
  password: '',
  isLoggingIn: false,
  isLoggedIn: false,
  error: null
});

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return state.merge({
        isLoggingIn: true,
        isLoggedIn: false,
        email: action.email,
        password: action.password // Note you shouldn't store user's password in real apps
      });
    case LOGGED_FAILED:
      return state.merge({
        error: action.error,
        isLoggingIn: false,
        isLoggedIn: false
      });
    case LOGGED_SUCCESSFULLY:
      return state.merge({
        error: null,
        isLoggingIn: false,
        isLoggedIn: true
      });
      break;
    default:
      return state;
  }

마지막으로 로그인 API 호출을 어디에 넣습니까?

이것이 바로 dispatch => {} 액션 크리에이터의 목적입니다. 부작용!

또 다른 액션 크리에이터 일뿐입니다. 다른 작업과 함께 사용하십시오.

import { LOGIN_ATTEMPT, LOGGED_FAILED, LOGGED_SUCCESSFULLY } from '../constants/LoginActionTypes';

export function loginError(error) {
  return { error, type: LOGGED_FAILED };
}

export function loginSuccess(response) {
  return dispatch => {
    dispatch({ response, type: LOGGED_SUCCESSFULLY });
    router.transitionTo('/dashboard');
  };
}

export function loginRequest(email, password) {
  const user = {email: email, password: password};
  return { user, type: LOGIN_ATTEMPT };
}

export function login(userData) {
  return dispatch =>
    fetch('http://localhost/login', {
      method: 'post',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        email: userData.email,
        password: userData.password,
      }),
    })
    .then(response => {
      if (response.status >= 200 && response.status < 300) {
        console.log(response);
        dispatch(loginSuccess(response));
      } else {
        const error = new Error(response.statusText);
        error.response = response;
        dispatch(loginError(error));
        throw error;
      }
    })
    .catch(error => { console.log('request failed', error); });
}

구성 요소에서

this.props.login(); // assuming it was bound with bindActionCreators before

// --or--

this.props.dispatch(login()); // assuming you only have dispatch from Connector

마지막으로, 이와 같은 대규모 액션 생성자를 자주 작성하는 경우, 비동기에 사용하는 약속과 호환되는 비동기 호출을위한 사용자 지정 미들웨어 를 작성하는 것이 좋습니다.

위에서 설명한 기술 ( dispatch => {} 서명이있는 액션 생성자)은 현재 Redux에 포함되어 있지만 1.0에서는 redux-thunk 라는 별도의 패키지로만 사용할 수 있습니다. 당신이 그것에있는 동안 당신은 redux-promise-middleware 또는 redux-promise를 확인하는 것이 좋습니다.

@gaearon : 박수 : 놀라운 설명이었습니다! ;) 확실히 문서로 만들어야합니다.

@gaearon 굉장한 설명! :트로피:

@gaearon 어떤 API 호출을 호출해야하는지 결정하기 위해 로직을 수행해야하는 경우 어떻게해야합니까? 한곳에 있어야하는 도메인 로직이 아닌가? In Action 제작자를 유지하는 것은 진실의 단일 소스를 깨는 것처럼 들립니다. 게다가, 대부분은 애플리케이션 상태의 값으로 API 호출을 매개 변수화해야합니다. 어떻게 든 논리를 테스트하고 싶을 가능성이 큽니다. 리듀서 (원자 플럭스)에서 API 호출을 만드는 것은 대규모 프로젝트에서 매우 유용하고 테스트 할 수 있음을 발견했습니다.

리듀서 (원자 플럭스)에서 API 호출을 만드는 것은 대규모 프로젝트에서 매우 유용하고 테스트 할 수 있음을 발견했습니다.

이로 인해 기록 / 재생이 중단됩니다. 부작용이있는 함수는 정의상 순수 함수보다 테스트하기가 더 어렵습니다. Redux를 이와 같이 사용할 수 있지만 디자인에 완전히 반대됩니다. :-)

In Action 제작자를 유지하는 것은 진실의 단일 소스를 깨는 것처럼 들립니다.

"단일 진실 소스"는 데이터 가 한 곳에 존재하고 독립적 인 사본이 없음을 의미

호출해야하는 API 호출을 결정하기 위해 몇 가지 논리를 수행해야하는 경우 어떻게해야합니까? 한곳에 있어야하는 도메인 로직이 아닌가?

리듀서는 동작에 의해 상태가 어떻게 변환되는지 지정합니다. 그들은 이러한 행동이 어디서 시작되었는지에 대해 걱정할 필요가 없습니다. 구성 요소, 액션 제작자, 기록 된 연속 세션 등에서 올 수 있습니다. 이것이 액션 사용 개념의 아름다움입니다.

모든 API 호출 (또는 호출되는 API를 결정하는 로직)은 리듀서보다 먼저 발생합니다. 이것이 Redux가 미들웨어를 지원하는 이유입니다. 위에서 설명한 Thunk 미들웨어를 사용하면 조건문을 사용하고 상태에서 읽을 수도 있습니다.

// Simple pure action creator
function loginFailure(error) {
  return { type: LOGIN_FAILURE, error };
}

// Another simple pure action creator
function loginSuccess(userId) {
  return { type: LOGIN_SUCCESS, userId };
}

// Another simple pure action creator
function logout() {
  return { type: LOGOUT };  
}


// Side effect: uses thunk middleware
function login() {
  return dispatch => {
    MyAwesomeAPI.performLogin().then(
      json => dispatch(loginSuccess(json.userId)),
      error => dispatch(loginFailure(error))
    )
  };
}


// Side effect *and* reads state
function toggleLoginState() {
  return (dispatch, getState) => {
    const { isLoggedIn } = getState().loginState;
    if (isLoggedIn) {
      dispatch(login());
    } else {
      dispatch(logout());
    }
  };
}

// Component
this.props.toggleLoginState(); // Doesn't care how it happens

액션 크리에이터와 미들웨어는 부작용을 수행하고 서로를 보완하도록 _ 설계되었습니다 _.
감속기는 상태 머신 일 뿐이며 비동기와 관련이 없습니다.

리듀서는 동작에 의해 상태가 어떻게 변환되는지 지정합니다.

이것은 참으로 유효한 포인트입니다. 감사합니다.

이 버전이 문서에 포함될 때까지 후손을 위해 다시 열겠습니다.

: +1 :

리듀서는 상태 머신이지만 일반적으로 액션 생성자도 그렇습니다 (하지만 암시 적으로).

사용자가 "제출"버튼을 두 번 클릭했다고 가정 해 보겠습니다. 처음에는 HTTP 요청을 서버 (액션 생성기)에 보내고 상태를 "제출 중"(리듀서에서)으로 변경합니다. 두 번째로 그렇게하고 싶지 않습니다.

현재 모델에서 액션 제작자는 현재 상태에 따라 전달할 액션을 선택해야합니다. 현재 "제출"하지 않은 경우-HTTP 요청을 보내고 하나의 작업을 전달합니다. 그렇지 않으면 아무 작업도 수행하지 않거나 경고와 같은 다른 작업을 전달합니다.

따라서 제어 흐름은 효과적으로 두 개의 상태 머신으로 분할되고 그중 하나는 암시 적이며 부작용으로 가득 차 있습니다.

이 Flux 접근 방식은 일반적인 웹 앱의 대부분의 사용 사례를 매우 잘 처리한다고 말하고 싶습니다. 그러나 복잡한 제어 로직이 있으면 문제가 될 수 있습니다. 기존의 모든 예제에는 복잡한 제어 로직이 없기 때문에이 문제는 다소 숨겨져 있습니다.

https://github.com/Day8/re-frame 은 유일한 FSM 역할을하는 단일 이벤트 핸들러가있는 다른 접근 방식의 예입니다.

그러나 감속기는 부작용이 있습니다. 따라서 이러한 경우 "재생"기능을 처리하는 방법이 흥미 롭습니다. https://github.com/Day8/re-frame/issues/86 에서 질문했습니다.

일반적으로 이것이 진짜 문제라고 생각하며 계속해서 나타나는 것은 놀라운 일이 아닙니다. 결국 어떤 솔루션이 나올지 보는 것은 흥미 롭습니다.

프레임 변경 및 부작용에 대해 계속 알려주세요!

내 책에는 괜찮은 Redux 웹 앱에는 3 가지 상태 유형이 있습니다.

1) 구성 요소보기 (React this.state). 이것은 피해야하지만 때로는 Redux와 독립적으로 구성 요소를 재사용하여 재사용 할 수있는 일부 동작을 구현하고 싶습니다.

2) 앱 공유 상태, 즉 Redux.state. 보기 계층이 사용자에게 앱을 제공하고보기 구성 요소가이를 사용하여 서로간에 "통신"하는 데 사용하는 상태입니다. 그리고이 상태는 결정이이 상태에 따라 달라질 수 있으므로 ActionCreators, Middleware, 뷰간에 "통신"하는 데 사용할 수 있습니다. 따라서 "공유"가 중요합니다. 하지만 완전한 앱 상태 일 필요는 없습니다. 또는 모든 것을 이러한 유형의 상태로 구현하는 것이 비실용적이라고 생각합니다 (행동 측면에서).

3) 다른 부작용을 일으키는 복잡한 모듈 / libs / 서비스가 보유하는 상태. 블라 다르가 설명하는 시나리오를 다루기 위해 이것을 쓸 것입니다. 또는 반응 라우터가 또 다른 예입니다. 자체 상태가있는 블랙 박스로 취급하거나 react-router 상태의 일부를 앱 공유 상태 (Redux.state)로 전환하도록 결정할 수 있습니다. 모든 요청과 타이밍을 영리하게 처리하는 복잡한 HTTP 모듈을 작성한다면 일반적으로 Redux.state의 요청 타이밍 세부 정보에 관심이 없습니다. ActionCreators / Middlewares의이 모듈 만 Redux.state와 함께 사용하여 새 Redux.state를 가져옵니다.

내 요청의 타이밍을 보여주는 뷰 컴포넌트를 작성하려면이 상태를 Redux.state로 가져와야합니다.

@vladar AC / MW가 암시 적 상태 머신이라는 의미입니까? 자체적으로 상태를 유지하지는 않지만 여전히 다른 곳에있는 상태에 의존하고 있으며이 상태가 시간에 따라 어떻게 진화하는지 제어 논리를 정의 할 수 있기 때문입니까? 어떤 경우에는 여전히 클로저로 구현되고 자체 상태를 유지하여 명시 적 상태 머신이 될 수 있다고 생각합니다.

또는 Redux.state를 "공개 상태"라고 부르고 다른 상태는 비공개라고 할 수 있습니다. 내 앱을 디자인하는 방법은 무엇을 비공개 상태로 유지하고 무엇을 공개 상태로 유지할지 결정하는 행위입니다. 캡슐화에 대한 좋은 기회처럼 보이므로 서로 영향을 미치는 방식이 지옥이되지 않는 한 상태를 여러 장소로 나누는 것이 문제가되지 않습니다.

블라 다르

그러나 감속기는 부작용이 있습니다. 그래서 그들이 그런 경우에 "재생"기능을 다루는 방법이 흥미 롭습니다

쉽게 재생하려면 코드가 결정적이어야합니다. Redux가 순수한 감속기를 요구함으로써 달성 한 것입니다. 결과적으로 Redux.state는 앱을 비 결정적 (비동기) 및 결정적 부분으로 나눕니다. 보기 구성 요소에서 미친 짓을하지 않는다고 가정하면 Redux.state 위에서 bahavior를 재생할 수 있습니다. 결정 론적 코드를 달성하기위한 첫 번째 중요한 목표는 비동기 코드를 멀리 이동하고 작업 로그를 통해 동기 코드로 변환하는 것입니다. Flux 아키텍처가 일반적으로하는 일입니다. 그러나 일반적으로 충분하지 않으며 다른 부작용 또는 변형 코드는 여전히 결정 론적 처리를 중단시킬 수 있습니다.

부작용 리듀서로 재생 가능성을 달성하는 것은 비현실적으로 어렵거나 불가능하거나 실제 효과가 거의없는 많은 코너 케이스에서 부분적으로 만 작동합니다.

쉬운 시간 여행을 달성하기 위해 Redux에서 수행 한 것처럼 작업 (항상 어렵습니다)을 재생하는 대신 앱 상태의 스냅 샷을 저장합니다.

쉬운 시간 여행을 달성하기 위해 Redux에서 수행 한 것처럼 작업 (항상 어렵습니다)을 재생하는 대신 앱 상태의 스냅 샷을 저장합니다.

Redux DevTools 는 스냅 샷과 작업을 모두 저장합니다. 작업이 없으면 감속기를 다시로드 할 수 없습니다. DevTools가 지원하는 워크 플로의 가장 강력한 기능입니다.

시간 여행은 _ 파견 된 (최종) 원시 작업 수준에서 발생하기 때문에 불순한 작업 제작자에게 잘 작동합니다 _. 이들은 일반 객체이므로 완전히 결정적입니다. 예, API 호출을 "롤백"할 수는 없지만 문제는 없습니다. 생성 된 원시 작업을 롤백 할 수 있습니다.

자체적으로 상태를 유지하지는 않지만 여전히 다른 곳에있는 상태에 의존하고 있으며이 상태가 시간에 따라 어떻게 진화하는지 제어 논리를 정의 할 수 있기 때문입니까?

그래, 그게 바로 내가 의미하는 바야. 그러나 제어 로직이 중복 될 수도 있습니다. 문제를 설명하는 일부 코드 (위의 예제에서 두 번 제출 클릭).

function submit(data) {
  return (dispatch, getState) => {
    const { isSubmitting } = getState().isSubmitting;
    if (!isSubmitting) {
      dispatch(started(data));

      MyAPI.submit(data).then(
        json => dispatch(success(json)),
        error => dispatch(failure(error))
      )
    }
  }
}

function started(data) {
   return { type: SUBMIT_STARTED, data };
}

function success(result) {
  return { type: SUBMIT_SUCCESS, result };
}

function failure(error) {
  return { type: SUBMIT_FAILURE, error };
}

그런 다음 감속기가 "isSubmitting"상태를 다시 확인합니다.

const initialState = new Immutable.Map({
  isSubmitting: false,
  pendingData: null,
  error: null
});

export default function form(state = initialState, action) {
  switch (action.type) {
    case SUBMIT_STARTED:
      if (!state.isSubmitting) {
        return state.merge({
          isSubmitting: true,
          pendingData: action.data
        });
      } else {
        return state;
      }
  }
}

따라서 두 곳에서 동일한 논리적 검사를 받게됩니다. 분명히이 예제에서 중복은 최소화되지만 더 복잡한 시나리오에서는 예쁘지 않을 수 있습니다.

마지막 예에서 체크는 감속기 안에 있어야한다고 생각합니다. 그렇지 않으면 빠르게 불일치로 내려갈 수 있습니다.

(그게 당신이 만드는 요점이라면 죄송합니다 ;-)

SUBMIT_STARTED 액션이 전달되었다는 사실에! isSubmitting이 이미 인코딩되어 있기 때문에 gaeron에 동의합니다. 액션이 어떤 로직의 결과 일 때 그 로직이 리듀서에서 복제되어서는 안됩니다. 그렇다면 감속기 책임은 SUBMIT_STARTED를 수신 할 때마다 다른 사람이 SUBMIT_STARTED를 결정하는 책임을 졌기 때문에 생각하지 않고 액션 페이로드로 상태를 업데이트하는 것입니다.

하나의 결정에 대해 책임을지는 것이 하나라는 것을 항상 목표로해야합니다.

감속기는 SUBMIT_STARTED 사실을 추가로 빌드하고 추가 로직으로 확장 할 수 있지만이 로직은 달라야합니다. Fe :

case SUBMIT_STARTED:
  if (goodMood) loading...
  else nothing_happens

누가 무엇을 책임 져야하는지 결정하는 것이 때때로 까다로울 수 있다고 상상할 수 있습니다. ActionCreator, 미들웨어, 독립형 복합 모듈, 감속기?

감속기에서 가능한 한 많은 결정을 내리고 순수하게 유지하는 것을 목표로 할 것입니다. 부작용 / 비 동기화에 대한 결정이 필요한 경우 AC / MW / somewhere_else로 이동합니다. 코드 재사용, 즉 리듀서 대 미들웨어와 관련하여 모범 사례가 어떻게 발전하는지에 따라 달라질 수 있습니다.

AC는 state.isSubmitting을 직접 변경할 수 없습니다. 따라서 논리가 그것에 의존하는 경우 AC는 state.isSubmitting이 논리와 동기화되도록 보장해야합니다. AC 로직이 새 데이터를 사용하여 state.isSubmitted를 true로 설정하고 읽기가 돌아왔다면 그 자체로 설정 될 것으로 예상합니다. 잠재적으로이 전제를 변경하는 다른 논리가 있어서는 안됩니다. ACTION은 동기화 기본 요소 자체입니다. 기본적으로 행동은 프로토콜을 정의하고 프로토콜은 명확하고 명확하게 정의되어야합니다.

하지만 나는 당신이 무슨 말을 하려는지 알고 있다고 생각합니다. Redux.state는 공유 상태입니다. 공유 상태는 항상 까다 롭습니다. AC 로직에 의해 예상치 못한 방식으로 상태를 변경하는 감속기에서 코드를 작성하는 것은 쉽습니다. 따라서 매우 복잡한 시나리오에서 AC와 감속기 사이의 논리를 동기화하는 것이 어려울 수 있다고 상상할 수 있습니다. 이로 인해 추적 및 디버깅이 어려울 수있는 버그가 발생할 수 있습니다. 이러한 시나리오의 경우 논리를 AC / 미들웨어로 축소하고 리듀서가 논리가 없거나 거의없는 잘 정의 된 동작을 기반으로 어리석게 만 작동하도록하는 것이 항상 가능하다고 생각합니다.

누군가는 항상 오래된 종속 AC를 끊는 새로운 감속기를 추가 할 수 있습니다. AC를 Redux 상태에 종속시키기 전에 두 번 생각해야합니다.

사용자 자격 증명과 함께 API 요청에서 반환 된 인증 토큰이 필요한 작업 생성자가 있습니다. 이 토큰에는 시간 제한이 있으며 무언가에 의해 새로 고쳐지고 관리되어야합니다. 당신이 제안하는 것은이 상태가 Redux.state에 속하지 않는다는 것을 나타내는 것 같습니다.

어디로 가야하나요? 개념적으로 Redux 저장소의 생성자에 불변의 외부 상태로 전달됩니까?

따라서 매우 복잡한 시나리오에서 AC와 감속기 사이의 논리를 동기화하는 것이 어려울 수 있다고 상상할 수 있습니다.

네. 나는 그것이 쇼 스토퍼라는 말은 아니지만 일관성이 없을 수 있습니다. 상태 머신의 요점은 나타나는 순서에 관계없이 이벤트에 반응하고 일관성을 유지하는 것입니다.

AC에서 이벤트의 적절한 순서에 의존하는 경우 암시 적으로 상태 엔진의 일부를 AC로 이동하고 감속기와 결합합니다.

아마도 그것은 선호의 문제 일 수도 있지만 스토어 / 리듀서가 항상 일관되게 작동하고 다른 곳에서 일관성을 유지하기 위해 외부에 의존하지 않을 때 훨씬 기분이 좋습니다.

AC를 Redux 상태에 종속시키기 전에 두 번 생각해야합니다.

복잡한 경우에는 피할 수 없다고 생각합니다 (부작용을 감속기 / 이벤트 핸들러로 옮기지 않고는).

"핫 리로딩 또는 리플레이 기능 삭제"와 "한 곳에서 상태 관리"라는 절충안 인 것 같습니다. 나중의 경우 re-frame 제안과 같은 실제 FSM 또는 Statecharts를 작성할 수 있으며, 전자의 경우 현재 Flux에서와 같이 더 임시적인 제어 로직입니다.

Re-frame을 통해 (너무 빨리) 읽었으며 Redux와 같은 종류의 구현 세부 사항 차이가 있습니다. Re-frame view 컴포넌트는 Observable을 기반으로하고, Events는 Actions, Re-frame은 생성자를 사용하지 않고 객체 (뷰 컴포넌트에서 구성됨)로 직접 이벤트 (액션)를 전달합니다. Event Handler는 순수하며 Redux와 동일합니다. 감속기.

부작용 처리는 많이 논의되지 않았거나 그것을 놓쳤습니다. 그러나 제가 가정하고있는 것은 그것들이 미들웨어에서 처리된다는 것입니다. 그리고 주요 차이점이 있습니다. 미들웨어는 이벤트 핸들러 (리듀서)를 감싸고 외부에서 구성하는 반면 Redux 미들웨어는 리듀서를 감싸지 않습니다. 즉, Re-frame은 순수한 감속기에 직접 부작용을 구성하는 반면 Redux는 분리 된 상태로 유지합니다.

그것은 Re-frame 이벤트를 기록하고 쉽게 재생할 수 없다는 것을 의미합니다.

가능한 불일치에 대해 이야기 할 때 공유 상태를 근본 원인으로 생각했고 Re-frame이 동일한 위험을 가지고 있다고 생각합니다.

차이점은 미들웨어와 감속기를 결합하는 것입니다. 미들웨어가 Re-frame에서 완료되면 결과를 이벤트 핸들러 (리듀서)에 직접 전달합니다.이 결과는 이벤트 / 액션으로 기록되지 않으므로 재생할 수 없습니다. 나는 Redux가 행동의 형태로 그 사이에 후크를 넣을 뿐이라고 말하고 싶습니다. 따라서 더 많은 타이핑 (액션 생성)을 희생하면서 더 많은 유연성과 아마도 그것을 할 수있는 더 많은 공간으로 리 프레임이하는 것과 같은 것을 기술적으로 달성 할 수 있다고 믿습니다. 잘못된.

결국 Redux가 Re-frame과 똑같은 접근 방식을 구현하는 것을 막는 것은 없습니다. 감속기를 매개 변수로 사용하는 모든 함수를 생성하고, 그 안에 일부 처리를 한 다음 결과와 함께 감속기 함수를 직접 호출하고 Reducer Middlewares 등으로 호출 할 수 있습니다. DevTools를 잃어 버리고 더 많은 커플 링을하면서 좀 더 쉽게 만들고 싶을 때입니다.

일부 단순화 (액션 감소)보다 Re-frame 접근 방식에 상당한 이점이 있다면 더 많이 생각해야합니다. 나는 그것을 빨리 읽었다 고 말했듯이 내가 틀렸다는 것을 증명하기 위해 열려 있습니다.

사실 나는 약간 틀렸다. 차이점은 Redux와 Re-frame 구현이 아니라 실제로 "부작용을 넣는 위치"에 있습니다.

이벤트 핸들러 (리듀서)에서이 작업을 수행하고 액션 생성자가 제어 흐름에 영향을주는 것을 허용하지 않으면 기술적으로 차이가 없습니다. Redux에서도 fsm / statecharts를 사용하고 제어 흐름을 한곳에 둘 수 있습니다.

그러나 실제로는 차이가 있습니다. @gaearon은 그것을 아주 잘 설명했습니다 : Redux는 당신의 감속기가 순수하기를 기대합니다. 그렇지 않으면 재생 기능이 중단됩니다. 따라서 Redux 디자인에 위배되므로 그렇게해서는 안됩니다 (감속기에 부작용을 넣는 것).

Re-frame은 또한 이벤트 핸들러가 순수하다고 말하지만 Readme에서도 HTTP 요청이 이벤트 핸들러에서 시작된다고 언급합니다. 그래서 이것은 저에게 약간 불분명하지만 그들의 기대는 다른 것 같습니다. 이벤트 처리자에게 부작용을 넣을 수 있습니다.

그런 다음 그들이 재생에 접근하는 방법이 흥미 롭습니다 (https://github.com/Day8/re-frame/issues/86에서 요청한 것입니다).

이벤트 핸들러가 부작용을 가질 수있을 때이를 수행하는 유일한 방법은 @ tomkis1이 언급 한 것입니다. 모든 이벤트 핸들러에서 반환 된 상태를 기록하는 것입니다 (모든 이벤트에서 감속기를 다시 실행하지 않음).

핫 리로딩은 "과거"이벤트에 영향을 줄 수 없다는 점을 제외하고는 여전히 작동 할 수 있습니다. 시간에 따라 일부 새로운 상태 분기 만 생성합니다.

그래서 디자인의 차이는 미묘하지만 저에게는 중요합니다.

나는 그들이 부작용을 일으키는 미들웨어로 순수한 이벤트 핸들러를 구성함으로써 HTTP 요청을한다고 생각합니다. 이 구성은 더 이상 순수하지 않지만 내부는 순수하게 유지되는 새로운 이벤트 처리기를 반환합니다. 나는 그들이 app-db (상태) 돌연변이와 부작용을 혼합하는 이벤트 핸들러를 만들 것을 제안하지 않는다고 생각합니다. 코드를보다 쉽게 ​​테스트 할 수 있습니다.

이벤트 핸들러의 결과를 기록하는 경우 핫 리로드 가능으로 만들 수 없으므로 즉시 코드를 변경할 수 있습니다. 미들웨어의 결과를 기록해야하고 그것은 Redux가하는 것과 똑같을 것입니다-이 결과를 액션으로 기록하고 그것을 감속기에 전달하십시오 (듣기).

Re-frame 미들웨어는 능동적이라고 말할 수 있지만 Redux는 반응성을 허용합니다 (모든 애드혹 감속기는 미들웨어 / ac의 결과를들을 수 있습니다). 제가 깨닫기 시작한 한 가지는 Flux와 미들웨어에서 주로 사용되는 AC는 컨트롤러와 동일하다는 것입니다.

내가 이해했듯이 @ tomkis1 은 모든 단일 돌연변이에 대해 수행되면 성능에 영향을 미칠 수 있다고 가정하므로 주어진 간격으로 저장 상태를 통해 시간

좋아요, 감속기 / 이벤트 핸들러가 완전한 새로운 상태를 반환한다는 것을 깨달았으므로 동일하게 말했습니다.

@merk 주말에는 여기에 오지 않기 때문에 아마도 월요일에 그것에 대한 생각을 쓰려고 노력할 것입니다.

Re-frame 문서는 이벤트 핸들러에서 서버와 대화 할 것을 권장합니다 : https://github.com/Day8/re-frame#talking -to-a-server

그래서 이것이 Redux와 다른 곳입니다. 그리고이 차이는 언뜻보기보다 더 깊습니다.

흠, Redux와의 차이점을 보지 못했습니다.

시작 이벤트 핸들러는 이러한 HTTP 요청에 대한 on-success 또는 on-fail 핸들러가 단순히 새 이벤트를 전달하도록 구성해야 합니다. 절대로 app-db를 직접 수정해서는 안됩니다. 그것은 항상 핸들러에서 수행됩니다.

이벤트를 Action으로 바꿉니다. Redux는 순수한 이벤트 핸들러에 대한 특별한 이름 인 감속기를 가지고 있습니다. 이번 주말에 뭔가 빠졌거나 뇌가 다운 된 것 같아요.

이벤트가 실행되는 방식 (대기열 및 비동기)에서 더 큰 차이를 느낄 수 있습니다. Redux는 상태 일관성을 보장하기 위해 작업별로 작업 동기화 및 잠금 단계 작업을 실행한다고 생각합니다. 이벤트를 저장하고 반복해서 재생하는 것이 동일한 종료 상태가 될지 확실하지 않기 때문에 재생성에 더 영향을 미칠 수 있습니다. 액션이 항상 순수한 코드를 트리거하는 Redux와 달리 어떤 이벤트가 부작용을 유발하는지 모르기 때문에 그렇게 할 수는 없습니다.

@vladap 내가 본 차이점을 요약하면 다음과 같습니다.

1.

• Redux에서는 생성자에서 서버 요청을 시작합니다 (이 문제의 원래 질문에 대한 @gaearon 응답 참조). 감속기는 순수해야합니다
• Re-frame에서는 이벤트 핸들러 (reducer)에서 수행합니다. 이벤트 핸들러 (감소 자)는 부작용이있을 수 있습니다.

2.

• 첫 번째 경우 제어 흐름은 AC와 감속기로 분할됩니다.
• 두 번째 경우에는 모든 제어 흐름이 이벤트 처리기 (감소 기)에 있습니다.

삼.

• 제어 흐름이 분할 된 경우-AC와 감속기간에 조정이 필요합니다 (암시 적 일지라도) : AC는 감속기에 의해 생성 된 상태를 읽습니다. 감속기는 AC에서 이벤트의 적절한 순서를 가정합니다. 감속기를 변경하면 AC에 영향을 미칠 수 있으며 그 반대의 경우도 마찬가지이므로 기술적으로 AC와 감속기의 커플 링을 도입합니다.
• 제어 흐름이 한곳에있는 경우-추가 조정이 필요하지 않습니다. 이벤트 처리기 / 감소 기에서 FSM 또는 상태 차트와 같은 도구를 사용할 수 있습니다.
• 
  
  
  
  1. 순수한 감속기를 적용하고 부작용을 AC로 이동시키는 Redux 방식으로 핫 리로딩 및 리플레이 가능
  
  
• 이벤트 핸들러 (리듀서)에서 부작용을 갖는 리 프레임 방식은 Redux에서 수행되는 것처럼 리플레이의 문을 닫지 만 (리듀서 재평가를 통해) 다른 (아마도 덜 강력한) 옵션은 여전히 ​​가능합니다- @ tomkis1이 언급했듯이

개발 경험의 차이에 관해서는 비동기 항목 (타이머, 병렬 http 요청, 웹 소켓 등)이 많은 경우에만 나타납니다. 동기화 항목의 경우 모두 동일합니다 (AC에는 제어 흐름이 없기 때문에).

내 요점을 더 명확하게하기 위해 이러한 복잡한 시나리오의 실제 사례를 준비해야한다고 생각합니다.

내가 당신을 미치게 할 수도 있습니다. 죄송하지만 우리는 기본적인 것에 동의하지 않습니다. 리 프레임 예제 코드를 읽어야 할 수도 있고 언젠가 Clojure를 배울 것입니다. 아마도 당신은 그랬을 것이므로 더 많이 알고 있습니다. 노력해 주셔서 감사합니다.

1.

Redux에서는 생성자에서 서버 요청을 시작합니다 (이 문제의 원래 질문에 대한 @gaearon 응답 참조). 감속기는 순수해야합니다
Re-frame에서는 이벤트 핸들러 (reducer)에서 수행합니다. 이벤트 핸들러 (감소 자)는 부작용이있을 수 있습니다.

내가 굵게 만든 문서는 이벤트 핸들러에서 webapi 호출을 시작한 다음 성공시 이벤트를 전달해야한다고 명시 적으로 말합니다. 동일한 이벤트 처리기에서이 전달 된 이벤트를 처리 할 수있는 방법을 이해하지 못합니다. 이 성공 이벤트는 라우터 (내 생각에 디스패처의 등식)로 전달되며 처리 할 또 다른 이벤트 핸들러가 필요합니다. 이 두 번째 이벤트 핸들러는 순수하고 Redux 감속기와 동일하며 첫 번째 이벤트 핸들러는 ActionCreator와 동일합니다. 나에게 그것은 똑같거나 중요한 통찰력을 분명히 놓친 것입니다.

개발 경험의 차이에 관해서는 비동기 항목 (타이머, 병렬 http 요청, 웹 소켓 등)이 많은 경우에만 나타납니다. 동기화 항목의 경우 모두 동일합니다 (AC에는 제어 흐름이 없기 때문에).

우리는 이것에 동의하지 않습니다. 비동기 작업은 실제로 중요하지 않으며 Redux에서 재생할 수 없으므로 여기에서 개발 경험이 없습니다. 복잡한 순수 감속기가 많을 때 차이가 나타납니다. Redux에서 상태 A, 일부 작업 시퀀스, 리듀서, 재생 및 상태 B를 가져올 수 있습니다. 모든 것을 동일하게 유지하지만 코드를 리듀서로 변경하고 핫 리로드하고 상태 A에서 동일한 작업 시퀀스를 재생하면 상태 C를 가져 와서 코드 변경의 영향을 즉시 확인합니다. @ tomkis1 접근 방식으로는 할 수 없습니다.

그 위에 테스트 시나리오를 구축 할 수도 있습니다. 초기 상태를 저장하고, 작업 시퀀스를 저장하고, 작업 시퀀스를 상태 A로 줄이고, 상태 B를 가져 와서 주장합니다. 그런 다음 동일한 상태 B가 될 것으로 예상되는 코드를 변경하고 테스트 시나리오를 재생하여 이것이 사실이며 변경 사항으로 인해 앱이 중단되지 않습니다. 나는 이것이 최선의 테스트 접근 방식이라고 말하지는 않지만 할 수 있습니다.

실제로 Haskellers처럼 함수형 프로그래밍의 하드 실무자라고 생각하는 Clojurists가 부작용을 최소한 어느 정도의 구성 없이도 순수 할 수있는 코드와 혼합하도록 권장한다면 상당히 놀랄 것입니다.

지연 평가 / 반응성은 다른 순수한 코드에서 가능한 한 부작용이있는 코드를 이동하는 기본적인 기술입니다. 게으른 평가는 하스켈이 마침내 실용적이지 않은 기능적 순도 개념을 적용하여 실용적인 것을하는 프로그램을 얻는 방법입니다. 완전히 순수한 프로그램은 많은 것을 할 수 없기 때문입니다. 모나 딕 구성 및 기타를 사용하여 전체 프로그램이 데이터 흐름으로 생성되고 파이프 라인의 마지막 단계를 순수하게 유지하고 코드에서 실제로 부작용을 호출하지 않기 위해 프로그램은 수행해야 할 작업에 대한 설명을 반환합니다. 느리게 실행되는 런타임으로 전달됩니다. 명령형 호출로 실행을 트리거하지 않습니다. 적어도 그것은 내가 조감도에서 함수형 프로그래밍을 이해하는 방법입니다. ActionCreators 및 반응성으로 시뮬레이션하는 그런 런타임이 없습니다. 면책 조항, 그것을 당연하게 여기지 마십시오. FP에 대해 그렇게 많이 읽지 않아서 여기에서 어떤 종류의 권위가 될 수 있다고 이해했습니다. 나는 떨어져 있을지 모르지만 실제로 내가 그 요점을 이해했다고 믿습니다.

동일한 이벤트 처리기에서이 전달 된 이벤트를 처리 할 수있는 방법을 이해하지 못합니다.

나는 그것을 말하는 것이 아니다. "부작용"이란 이벤트 핸들러 (리듀서)에서 시작된 HTTP 요청을 의미합니다. IO를 수행하는 것은 함수 반환에 영향을주지 않더라도 부작용입니다. 성공 / 오류 처리기에서 상태를 직접 수정하는 측면에서 "부작용"을 의미하지는 않습니다.

이 두 번째 이벤트 핸들러는 순수하고 Redux 감속기와 동일하며 첫 번째 이벤트 핸들러는 ActionCreator와 동일합니다.

첫 번째는 Action Creator와 동등하다고 생각하지 않습니다. 그렇지 않으면 왜이 작업을 수행하기 위해 액션 크리에이터가 필요합니까? 감속기에서도 똑같이 할 수 있다면?

@ tomkis1 접근 방식으로는 할 수 없습니다.

동의하다. 이것이 제가 "다른 (아마도 덜 강력한) 옵션"을 썼을 때 의미했던 것입니다.

첫 번째는 Action Creator와 동등하다고 생각하지 않습니다. 그렇지 않으면 왜이 작업을 수행하기 위해 액션 크리에이터가 필요합니까? 감속기에서도 똑같이 할 수 있다면?

ActionCreators는 순수 앱 (다시 재생할 수 있음)에서 부작용을 분리하는 데 사용됩니다. Redux가 설계 되었기 때문에 감속기에서 부작용을 수행 할 수 없습니다 (안됩니다). 부작용 코드를 배치 할 수있는 또 다른 구조가 필요합니다. Redux에서 이러한 구성은 AC 또는 미들웨어입니다. 리 프레임에서 내가 볼 수있는 유일한 차이점은 미들웨어가하는 일과 핸들러가 트리거되기 전에 이벤트 (액션)를 변환하는 미들웨어가 없다는 것입니다.

AC / 미들웨어 대신 실제로 사용할 수있는 모든 것-util 모듈, 서비스 (예 : Angular 서비스), AC 또는 미들웨어로 인터페이스하고 API를 작업으로 변환하는 별도의 lib로 빌드 할 수 있습니다. AC는이 코드를 배치하기에 적합한 장소가 아닙니다. AC는 인수에서 액션 객체를 구성하는 단순한 작성자 / 팩토리 일뿐입니다. 내가 순수 주의자가되고 싶다면 부작용 코드를 엄격하게 미들웨어에 배치하는 것이 낫습니다. ActionCreator는 일종의 컨트롤러 책임에 대한 잘못된 용어입니다. 그러나이 코드가 한 줄짜리 webapi 호출이면 간단히 AC 내부에 넣는 경향이 있으며 간단한 앱의 경우 괜찮을 수 있습니다.

AC, 미들웨어, 타사 라이브러리는 서비스 계층이라고 부르는 계층을 형성합니다. 기존 Facebook WebApiUtils는 react-router를 사용하고 변경 사항을 듣고 Redux.state를 업데이트하는 작업으로 변환하는 것처럼이 계층의 일부가됩니다. Relay는 서비스 계층으로 사용될 수 있습니다 (앱 /보기에 Redux를 사용하는 것보다 상태). 대부분의 타사 라이브러리가 현재 프로그래밍되어 있기 때문에 재생이 잘되지 않습니다. 분명히 나는 ​​모든 것을 처음부터 다시 작성하고 싶지 않습니다. 내가 생각하는 방법은 이러한 라이브러리, 서비스, 유틸리티 등이 브라우저 환경을 확장하여 재생 가능한 앱을 빌드 할 수있는 플랫폼을 함께 형성한다는 것입니다. 이 플랫폼은 부작용으로 가득 차 있습니다. 실제로 제가 의도적으로 부작용을 옮기는 곳입니다. 이 플랫폼 API를 작업으로 변환하고 내 앱은 이러한 작업 개체를 수신하여이 플랫폼에 간접적으로 연결합니다 (위의 게시물에서 설명하려고 한 Haskell 접근 방식을 시뮬레이션하려고 시도 함). 이것은 순수성을 달성하는 방법 (아마도 절대적인 학문적 의미가 아닐 수도 있음)을 달성하지만 부작용을 유발하는 방법에 대한 함수형 프로그래밍의 일종의 해킹입니다.

헷갈리는 또 다른 것이 있지만 오해 할 수 있습니다. 복잡한 논리의 경우 모든 것을 한곳에 두는 것이 유익하다고 말씀하신 것 같습니다. 나는 상당히 반대라고 생각합니다.

이 전체 액션 비즈니스는 개념적으로 DOM 이벤트와 유사합니다. 내 비즈니스 코드를 fe 브라우저가 mousemove 이벤트를 감지하는 코드와 혼합하고 싶지는 않지만 여러분도 마찬가지입니다. 다행히도 나는 이러한 책임이 잘 분리되어 있기 때문에 addListener ( 'mousemove', ...) 위에서 작업하는 데 익숙합니다. 요점은 내 비즈니스 로직에 대한 우려를 잘 분리하는 것입니다. ActionCreators, 미들웨어는이를위한 도구입니다.

내 비즈니스 요구에 잘 맞지 않는 구식 webapi에 대해 앱을 작성한다고 상상해보십시오. 필요한 데이터를 얻으려면 몇 개의 끝점을 호출하고 그 결과를 사용하여 다음 호출을 만든 다음 모든 결과를 Redux.state에서 사용할 표준 형식으로 병합해야합니다. 이 논리는 내 감속기에 누출되지 않으므로 감속기의 데이터를 반복해서 변환 할 필요가 없습니다. 미들웨어에있을 것입니다. 효과적으로 나는 지저분한 구식 API를 격리하고 멋진 API에 대해 작성되는 내 비즈니스 앱을 개발할 것입니다. 일단 완료되면 webapi를 다시 빌드하기 위해 변경 한 다음 미들웨어를 다시 작성합니다.

따라서 모든 것을 한곳에 모아 두는 것은 쉬운 앱으로 보입니다. 그러나 복잡한 일과는 정반대로 좋은 분리가 유익하다고 생각합니다. 그러나 당신이 언급 한 당신의 요점이나 사용 사례를 이해하지 못했을 수도 있습니다.

실제로, 아마도 나는 일반적으로 순수한이 코드에 대한 재생 및 테스트 가능성을 제공하기 때문에 리듀서로 데이터 변환을 표준 형식으로 옮기고 감속기 구성을 대신 사용할 것입니다.

동일한 이벤트 처리기에서이 전달 된 이벤트를 처리 할 수있는 방법을 이해하지 못합니다.
나는 그것을 말하는 것이 아니다.

webapi 호출을 감속기 논리와 혼합하여 한곳에두기를 원한다고 생각했습니다. 내가 말하는 것은 성공시 이벤트를 발송할 것을 제안하기 때문에 다시 프레임에서하지 않는다는 것입니다.

webapi-> 많은 논리-> webapi-> 많은 논리-> ...-> 감속기에 대한 결과, 한 번의 클릭으로 전체 체인이 트리거되는 상황이있을 수 있습니다. 이러한 경우 대부분의 논리는 아마도 AC에있을 것이며 모든 부작용이 끝날 때까지 나누지 않을 것입니다. 이것이 당신이 말하는 것입니까?

여기서 할 수있는 최선의 방법은 테스트 가능성을 위해 논리를 순수 함수로 옮기는 것이지만 AC 범위에서 호출됩니다.

간접적으로 연결된 일련의 이벤트 핸들러로 할 수있는 가능성을 좋아하지 않는다고 생각합니다. Promise 또는 Observable 체인 일 것입니다.

경험 많은 Reduxers는 그 생각에 대해 다른 의견을 가질 수 있습니다 ( @gaearon , @johanneslumpe , @acdlite , @emmenko ...)

@vladap 나는이 대화 가이 문제의 주제에서 너무 멀리 떨어진 것 같습니다. 이미 여기에서 내 의견의 요점을 언급했습니다.

따라서 매우 복잡한 시나리오에서 AC와 감속기 사이의 논리를 동기화하는 것이 어려울 수 있다고 상상할 수 있습니다.

빠른 예 :

상황 1 : 페이지 어딘가에 상위 10 명의 블로그 작성자 목록이 있습니다. 이제 블로그에서 게시물 범주를 삭제했습니다. 성공적으로 삭제되면 서버에서이 작성자 목록을 업데이트하여 최신 상태로 만들어야합니다.

상황 2 : 당신은 다른 페이지에 있습니다. 작성자 목록은 없지만 상위 10 개 댓글 목록이 있습니다. 블로그 게시물의 일부 카테고리를 삭제할 수도 있으며 성공적으로 삭제되면 댓글 목록을 업데이트해야합니다.

그렇다면 상태 엔진 수준에서 이것을 어떻게 처리할까요? (또한 도움을 받기 위해 React 후크를 사용할 수 있지만 좋은 상태 엔진은 자체적으로 일관성을 유지할 수 있어야합니다)

옵션 :
A)이 논리를 AC에 넣습니다. 그런 다음 AC는 CategoryApi (삭제)를 터치하고 userList 주 및 commentList 주 (현재 주에있는 목록 확인)를 읽고 UserListApi 와 대화합니다. CommentListApi (목록 새로 고침) + TOP_AUTHORS_UPDATED 및 / 또는 TOP_COMMENTS_UPDATED 디스패치. 따라서 기본적으로 3 개의 다른 도메인을 터치합니다.

B) 이벤트 핸들러 userList 및 commentList 넣습니다. 이러한 핸들러는 모두 DELETE_CATEGORY_SUCCESS 이벤트를 수신 한 다음 API 서비스를 호출하고 TOP_AUTHORS_UPDATED / TOP_COMMENTS_UPDATED 이벤트를 전달합니다. 따라서 각 핸들러는 자체 도메인의 서비스 / 상태 만 터치합니다.

이 예제는 아마도 너무 단순 할 수 있지만,이 수준에서도 AC에서 API 호출을 사용하면 상황이 덜 예뻐집니다.

차이점은 리 프레임의 이벤트 핸들러와 달리 ActionCreators가 비즈니스 로직을 사전에 처리한다는 사실에서 비롯됩니다. 그리고 DOM 이벤트를 기반으로 하나의 AC 만 실행할 수 있습니다. 이 최상위 AC는 다른 AC를 호출 할 수 있습니다. UserListApi 및 CommentListApi에 대해 별도의 AC가있을 수 있으므로 도메인이 더 잘 분리되도록 할 수 있지만 항상이를 연결하는 AC (컨트롤러와 같은)가 있어야합니다. 이 부분은 꽤 고전적인 명령 코드이며 re-frame은 완전히 이벤트 기반입니다. 약간의 작업을 통해 선호하는 접근 방식, 이벤트 기반, 관찰 가능 항목, cps 등으로 대체 할 수 있습니다.

@vladap 다른 접근 방식이 실행 가능한지 확인하는 것은 흥미로울 것입니다. 리듀서가 부작용을 가질 수 있지만 리플레이에서 무시 될 수 있도록 분리 할 수도 있습니다.

감속기 서명이 다음과 같이 변경된다고 가정 해 보겠습니다. (state, action) => (state, sideEffects?) 여기서 sideEffects가 클로저입니다. 그런 다음 컨텍스트 프레임 워크에 따라 이러한 sideEffect를 평가하거나 무시할 수 있습니다 (재생의 경우).

그러면 원래 문제 설명의 예는 다음과 같습니다.

export default function user(state = initialState, action) {
  switch (action.type) {
    case LOGIN_ATTEMPT:
      return [state, () => {LoginApiCall.login(action.user)}];
    case LOGGED_FAILED:
      // do something
      return state;
    case LOGGED_SUCCESSFULLY:
      // do something else
     return state;
    default:
      return state;
  }
}

(다른 모든 것은 거의 동일하게 유지됩니다)

최소한 제어 흐름이 한곳에 있고 부작용은 항상 간단합니다 (비동기 처리기에서 다른 작업 / 이벤트를 만들고 로직이 감속기에 남아 있기 때문에 더 많은 코드가 재생되기 때문입니다).

일반 FSM 또는 Statechart와 유사한 코드를 작성할 수도 있습니다 (감속기 / 이벤트 처리기 구성 포함).

또한 액션 생성자에서 미리 정의 된 서명으로 클로저를 반환 할 필요가 없습니다.

이 접근 방식이 잠재적으로 어떤 문제를 일으킬 수 있는지는 확실하지 않지만, 나로서는 그럴 가치가 있습니다.

감속기 시그니처가 다음과 같이 변경된다고 가정합니다. (state, action) => (state, sideEffects?) 여기서 sideEffects는 클로저입니다. 그런 다음 컨텍스트 프레임 워크에 따라 이러한 sideEffect를 평가하거나 무시할 수 있습니다 (재생의 경우).

이것은 실제로 Elm이 (State, Action) => (State, Request?) 했던 것과 비슷합니다. 나는 아직 어떤 예도 보지 못했지만 누군가 이것을 탐구하고 싶다면 자유롭게 느끼십시오.

영감을 얻을 수있는 또 다른 접근법은 Actor 모델 ( Akka Persistance , PersistentFSM) 위에 이벤트 소싱을 구현하는 것입니다. 나는 그것이 더 낫다고 말하지는 않지만 다른 시도를 아는 것이 나쁘지 않습니다. 액터는 부작용을 사용할 수 있지만 올바르게 기억하는 경우 재생 방법을 명시적인 코드로 작성해야하는 경우가 있습니다.

재생 기능이 코드가 속한 곳의 결정을 왜곡 할 수 있습니다. 우리가 생각하기 시작하는 것 같습니다. "나는이 리 플레이어 블을 원하므로 감속기로 가야합니다". 책임 / 역할에 따라 분할하지 않고 비즈니스 로직을 인위적으로 분할하여 재생 가능하게 만드는 경향이 있기 때문에 경계가 명확하지 않은 코드로 이어질 수 있습니다.

재생 기능을 제쳐두고 비즈니스 코드를 작성하는 방법은 무엇입니까? 나는 내 비즈니스 로직을 액션 로그 앞에두고 한곳에 두는 것을 목표로합니다. 비즈니스 로직 상태 머신 또는 내가 사용하는 모든 것은 복잡한 결정을 모두 수행하여 이미 해결 된 FACTS (액션) 스트림을 생성합니다. Reducer는 일반적으로 간단한 업데이트 프로그램이며 주요 책임은 Redux.state에 작업 페이로드를 적용하는 방법입니다. 그들은 몇 가지 논리를 가질 수 있지만 사실을 다르게 해석하여 사실 (액션) 스트림에 대한 또 다른 종류의 관점을 얻어 사용자에게 제공 할 수 있습니다.

책임을 분담하기 위해 저도 이런 식으로 생각하고 싶습니다. 서버에서 재 구현하기 위해 잠재적으로 어떤 코드를 요청할 수 있습니까? Fe는 계산 비용이 많이 드는 비즈니스 논리, 보안상의 이유, 인텔리전스 속성을 숨기는 방식으로 느린 장치를 더 잘 지원합니다. 뷰 레이어에 바인딩되어 있기 때문에 리듀서에서 서버로 로직을 쉽게 이동할 수 없습니다. 복잡한 비즈니스 로직이 작업 로그 앞에 작성되면 동일한 작업 스트림으로 변환되는 REST 호출로 대체 할 수 있으며 내 뷰 레이어가 작동해야합니다 (아마도).

단점은 Akka Persistance와 달리이 코드를 재생하는 방법이 없다는 것입니다.

언젠가는 Elm에 대해 자세히 살펴보고 귀하의 제안이 어떻게 작동하는지 이해해야합니다.

@gaearon Elm을 //gist.github.com/evancz/44c90ac34f46c63a27ae- 비슷한 아이디어 (하지만 훨씬 더 고급).

작업 (http, db 등) 및 효과 (작업 대기열)의 개념을 소개합니다. 따라서 "리듀서"는 실제로 새로운 상태와 효과를 반환 할 수 있습니다.

이것에 대한 멋진 점은 (그리고 저는 이런 식으로 생각하지 않았습니다)-감속기를 연결하면서 작업을 수집 할 수 있다면-나중에이 목록에 일부 기능을 적용 할 수 있다는 것입니다. http 요청을 일괄 처리하고 DB 쿼리를 트랜잭션으로 래핑 할 수 있다고 가정 해 보겠습니다.

또는 효과에 대한 멍청이 인 "재생 관리자"라고 말할 수 있습니다.

@merk 나는 대부분이 이미 작성되었다고 생각합니다. 이런 종류의 자율적 인 부작용 코드가 아마도 가장 까다로울 것입니다. 시간 여행이 동일한 코드에서 실행되고 간격이 재생 모드에서도 시작된다고 가정하면 간격이 시간 여행과 동기화되지 않기 때문에 재생시 혼란을 일으킬 수 있습니다.

일반적인 애플리케이션은 사용자에게 제공되는 토큰 및 만료 카운트 다운이 필요하지 않으므로 기술적으로 Redux.state에있을 필요가 없습니다. 관리자 앱에 필요할 수 있습니다. 따라서 자신에게 맞는 방식으로 구현할 수 있습니다.

한 가지 옵션은 로그인 AC에서 만료 카운트 다운을 시작하는 것이며 끝없이 실행되고 앱과 함께 죽거나 로그 오프가이를 정리해야한다고 가정합니다. 간격이 트리거되면 토큰을 확인하는 데 필요한 작업을 수행하고 만료되면 LOGIN_EXPIRED 작업을 전달하고 수신 감속기가 사용자 세션을 지우고 위치를 변경하여 라우터 전환을 / login으로 트리거합니다.

또 다른 방법은 타사 lib를 사용하고 이에 대한 우려를 위임하고 해당 API를 LOGIN_EXPIRED 작업으로 변환하는 것입니다. 또는 뷰 레이어에서 필요하지 않은 경우 직접 작성하고 여기에 토큰 및 카운트 다운 상태를 유지합니다.

Redux.state에 유지할 수 있지만이 상태는 휘발성입니다. 큰 상태에서 우리는 전역 변수를 사용한 프로그래밍과 동일한 문제에 도달 할 수 있습니다. 그리고 그것을 테스트하는 것은 어렵고 아마도 불가능할 것입니다. 리듀서를 테스트하는 것은 쉽지만 한 리듀서 만 상태 객체의 특정 키를 업데이트 할 때 작동한다는 것을 증명합니다. 이것은 다른 자질의 개발자가 많은 대규모 프로젝트에서 나빠질 수 있습니다. 누구나 리듀서를 작성하기로 결정할 수 있고 상태의 일부가 업데이트하기에 좋다고 생각할 수 있으며 가능한 모든 업데이트 시퀀스에서 모든 리듀서를 함께 테스트하는 방법을 상상할 수 없습니다.

사용 사례에 따라이 상태는 로그인이기 때문에 보호하는 것이 합리적 일 수 있습니다. 매우 중요한 기능이며 분리되어 있습니다. 이 상태가 뷰 레이어에 필요한 경우 반응 라우터 위치 상태가 주변의 일부 예에서 Redux.state에 복제되는 것과 유사한 방식으로 Redux.state에 복제합니다. 당신의 주와 팀이 작고 잘 행동한다면 한곳에 두는 것이 좋습니다.

트윗 담아 가기

와, 그 느릅 나무 요점은 정말 멋져요! 또한 Cycle.js "드라이버"아키텍처를 생각 나게합니다.

@merk 사실, 자율 LOGIN_EXPIRED는 리플레이에 큰 영향을주지 않을 것입니다. 왜냐하면 그것은 액션 로그의 끝에 들어가서 리플레이에 의해 즉시 처리되지 않을 것이고 아마도 액션 로그에 전혀 도착하지 않을 것이기 때문입니다.-모르겠습니다. 재생이 정확히 어떻게 구현되는지.

@gaeron 상위 수준에서 Elm과 Cycle이 올바르게 이해하면 설명하려는 패턴을 구현하는 것 같습니다. 기본 플랫폼을 제공하는 브라우저가 있습니다.이 플랫폼을 서비스 계층 (http, db ...)으로 확장하여 앱용 플랫폼을 구축합니다. 그런 다음 서비스 계층과 상호 작용하고 순수한 앱이 간접적으로 통신 할 수 있도록하는 일종의 접착제가 필요하므로 내 앱이 원하는 작업을 설명 할 수 있지만 실제로 실행하지는 않습니다 (Cycle 드라이버로 전송 된 메시지, Elm Effects 작업 목록 포함). 내 앱이 데이터 구조를 사용하여 "프로그램"을 빌드하고 있다고 말할 수 있습니다 (데이터 만트라로 코드에 대해 상기시켜줍니다). 그런 다음 실행을 위해 서비스 계층으로 전달되고 내 앱은이 "프로그램"의 결과에만 관심이 있습니다. 그 상태로.

@merk : 더. 토큰 및 만료가 Redux.state / 또는 다른 js 서비스의 어느 곳에 나 배치되는 경우 사용자가 새 탭에서 앱을 열 때 전송되지 않습니다. 사용자가 로그인 상태를 유지하기를 기대합니다. 그래서 저는이 상태가 실제로 SessionStore에 있어야한다고 가정합니다.

그것 없이도 토큰 만료가 사용자 정보를 즉시 정리하고 / login으로 전환하는 것을 의미하지 않을 때 상태가 분리 될 수 있습니다. 사용자가 상호 작용을 통해 서버를 만지지 않을 때까지 (캐시 된 데이터가 충분 함) 계속 작업 할 수 있으며 LOGIN_EXPIRED 작업은 서버가 필요한 작업을 수행 한 후에 만 ​​트리거됩니다. Redux.state를 기반으로하는 isLogged 상태는 유효한 토큰이 존재 함을 의미 할 필요가 없습니다. Redux.state의 isLogged 상태는 렌더링 할 항목을 결정하는 데 사용되며, 토큰 주변의 상태는 뷰 레이어에 숨겨 질 수 있으며 뷰 레이어에 영향을주는 것을 제외하고 액션과 리듀서를 작성하지 않고도 액션 생성자 수준에서만 유지됩니다.

@vladar 나는 당신의 일반적인 요점을 얻을 수 있다고 생각합니다. 나는 그것을 전에 깨닫지 못한 것 같습니다.

감속기에서 작업 생성자에게 제어를 반환하고 일부 값을 전달하는 방법은 쉽지 않습니다. 이러한 값은 렌더링에 필요하지 않고 일시적이지만 비동기 작업을 시작하는 데 필요하다고 가정 해 보겠습니다.

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
}

reducer() {
  case ACTION1
    ... some logic L2
    ... x, y result from L2
    ... some logic L3
    ... resulting in new state
    ... return new state
}

감속기에서 계산 된 x, y를 사용하여 비동기 작업을 시작하는 방법에는 3 가지 옵션이 있습니다. 그들 중 어느 것도 완벽하지 않습니다.

1) 감속기에서 액션 생성기로 로직을 이동하고 핫 리로드의 힘을 줄입니다. Reducer는 멍청한 상태 업데이트 프로그램이거나 논리 L3 이상입니다.

2) x, y를 Redux.state에 저장하고 임시 / 일시적인 값으로 오염시키고 기본적으로 감속기와 액션 제작자 사이의 글로벌 커뮤니케이션 채널로 사용합니다. 실제 상태라면 괜찮다고 생각하지만 이런 가치관은 아닙니다. 액션 제작자가 다음으로 변경됩니다.

actionCreator() {
  ... getState
  ... some logic L1
  ... dispatch({ACTION1})
  // I assume I get updated state if previous dispatch is sync.
  // If previous dispatch is async it has to be chained properly.
  // If updated state can't be received here after a dispatch
  // then I would think there is a flaw.
  ... getState
  ... asyncOperation(state.x, state.y)
}

3) x, y를 상태로 저장하고 일부 구성 요소에서 소품으로 사용하고 componentWillReceiveProps를 사용하여 전체 뷰 레이어 루프를 통해 터널링하여 새 작업 생성자와 비동기 작업을 트리거합니다. 내게 묻는다면 최악의 옵션은 비즈니스 로직을 사방으로 퍼뜨리는 것입니다.

블라 다르
일반적으로이 작업의 결과가 작업으로 압축되고 감속기에 의해 전달 및 적용되는 한 비동기가 시작되는 위치는 중요하지 않습니다. 동일하게 작동합니다. 액션 생성 자나 상점에서 비동기를 시작해야하는 경우 바닐라 플럭스와 동일한 논의입니다.

Redux가 재생시 이러한 비동기 호출을 식별하고 무시할 수 있어야합니다.

감속기에서 작업 생성자에게 제어를 반환하고 일부 값을 전달하는 방법은 쉽지 않습니다.

이것이 증상 중 하나라고 말하고 싶습니다. 두 번째 예는 내 관점을 매우 잘 보여줍니다 (아래 참조).

일반화 된 상태 전환 흐름을 고려하십시오 (FSM 세계에서) :

1. 이벤트 도착
2. 현재 상태가 주어지면 FSM은 새로운 목표 상태를 계산합니다.
3. FSM은 현재 상태에서 새 상태로 전환하는 작업을 수행합니다.

현재 상태가 중요합니다! 동일한 이벤트는 현재 상태에 따라 다른 결과로 이어질 수 있습니다. 결과적으로 3 단계에서 다른 작업 시퀀스 (또는 인수)가 발생합니다.

따라서 이것은 액션이 동기화 될 때 Flux에서 상태 전환이 작동하는 방식입니다. 감속기 / 저장소는 실제로 FSM입니다.

그러나 비동기 작업은 어떻습니까? 비동기 작업을 사용하는 대부분의 Flux 예제는 반전 된 것으로 생각하게합니다.

1. AC는 비동기 작업을 수행합니다 (현재 상태에 관계없이).
2. AC는이 작업의 결과로 작업을 전달합니다.
3. Reducer / Store가 처리하고 상태를 변경합니다.

따라서 현재 상태는 무시되고 대상 상태는 항상 동일한 것으로 간주됩니다. 실제로 일관된 상태 전환 흐름은 여전히 ​​동일합니다. 그리고 다음과 같아야합니다 (AC 포함).

1. AC는 조치가 전달되기 전에 현재 상태를 가져옵니다.
2. AC 파견 조치
3. AC는 조치 후 새로운 상태를 읽습니다.
4. 조치 전과 후 상태가 주어짐-수행 할 작업 (또는 인수로 전달할 값)을 결정합니다.

두 번째 예입니다. 이 모든 단계가 항상 필요하다는 것은 아닙니다. 종종 일부를 생략 할 수 있습니다. 그러나 복잡한 경우에는 그렇게 행동해야합니다. 모든 상태 전환의 일반화 된 흐름입니다. 또한 FSM의 경계가 AC 대 감속기 / 저장소로 이동했음을 의미합니다.

그러나 경계를 이동하면 다른 문제가 발생합니다.

1. 비동기 작업이 저장 / 감속기에있는 경우 동일한 이벤트에 반응하는 두 개의 독립적 인 FSM을 가질 수 있습니다. 따라서 새로운 기능을 추가하려면 기존 이벤트에 반응하는 저장소 / 감속기를 추가하기 만하면됩니다.
   그러나 AC에서 작업을 수행하려면 저장소 / 리듀서를 추가하고 논리의 비동기 부분을 추가하여 기존 AC로 이동하여 편집해야합니다. 다른 감속기에 대한 비동기 논리가 이미 포함되어 있다면 멋지지 않습니다.
   그러한 코드를 유지하는 것은 분명히 더 어렵습니다.
2. 동기화 작업과 비동기 작업의 경우 앱의 제어 흐름이 다릅니다. 동기 동작의 경우 리듀서가 전환을 제어합니다. 비동기의 경우-AC는이 이벤트 / 동작에 의해 잠재적으로 발생할 수있는 모든 전환을 효과적으로 제어합니다.

대부분의 문제는 대부분의 웹 앱의 간단한 상태 요구 사항에 의해 숨겨져 있습니다. 그러나 복잡한 상태 저장 앱이있는 경우 이러한 상황에 확실히 직면하게됩니다.

대부분의 경우 모든 종류의 해결 방법을 찾을 수 있습니다. 그러나 상태 전환 논리가 더 잘 캡슐화되고 FSM이 AC와 감속기간에 분리되지 않은 경우 처음부터이를 피할 수 있습니다.

불행하게도 상태 전환의 "부작용"부분은 여전히 ​​상태 전환의 일부이며 별도의 독립적 인 논리 부분이 아닙니다. 그래서 (state, action) => (state, sideEffects) 이 더 자연스럽게 보입니다. 예, 더 이상 "감소"서명이 아닙니다. %)하지만 프레임 워크의 도메인은 데이터 변환이 아니라 상태 전환입니다.

액션 생성 자나 상점에서 비동기를 시작해야하는 경우 바닐라 플럭스와 동일한 논의입니다.

예, 그러나 Flux는 비동기 콜백에서 dispatch ()를 직접적으로 변경하는 한 스토어에 비동기 항목을 갖는 것을 금지하지 않습니다. 대부분의 구현에서 비동기를 위해 AC를 사용하는 것이 좋습니다. 개인적으로 나는 그것이 MVC의 회상이라고 생각한다. 왜냐하면 AC를 컨트롤러로 취급하는 것보다 정신적으로 FSM으로 전환하는 것이 정신적으로 편리하기 때문이다.

블라 다르

(state, action) => (state, sideEffects)

그냥 생각. 즉, combineReducers 함수의 반환 유형을 [state, SideEffects] 또는 [state, [SideEffects]]로 변경하고 리듀서의 SideEffect를 결합하도록 코드를 변경해야합니다. 원래 (상태, 조치) => 상태 감속기 유형은 계속 지원 될 수 있습니다. 이는 combineReducer가 유형을 [상태] 또는 [상태, []]로 강제 (상태) 리턴하기 때문입니다.

그런 다음 Redux 어딘가에 SideEffect를 실행하고 전달해야합니다. 새로운 상태를 적용하고 SideEffects 목록을 실행하고 디스패치하는 Store.dispatch ()에서 수행 할 수 있습니다. 나는 우리가 멋진 끝없는 재귀에 들어갈 수 있는지 생각하고 있습니다.

또는 미들웨어 수준의 어딘가에서 실행될 수 있지만 Store.dispatch가 작업과 함께 SideEffects 목록을 반환해야한다고 생각합니다.

@vladar https://github.com/gaearon/redux/issues/291#issuecomment -125267259

블라 다르

예, 그러나 Flux는 비동기 콜백에서 dispatch ()를 직접적으로 변경하는 한 스토어에 비동기 항목을 갖는 것을 금지하지 않습니다. 대부분의 구현에서 비동기를 위해 AC를 사용하는 것이 좋습니다. 개인적으로 나는 그것이 MVC의 회상이라고 생각한다. 왜냐하면 AC를 컨트롤러로 취급하는 것보다 정신적으로 FSM으로 전환하는 것이 정신적으로 편리하기 때문이다.

ActionCreators를 컨트롤러로 대하는 것이 좋은 사고 방식이 아니라는 데 동의합니다. 복잡한 논리의 경우 감속기에서 다시 AC로 제어를 되돌려 야한다고 생각하는 루트 원인입니다. 그럴 필요 없어요. AC가 비동기를 처리하는 경우 요청 처리기와 비슷해야합니다. 다른 곳에서 내린 결정을 기반으로 실행되며이 요청은 도메인을 가로 질러서는 안됩니다.

컨트롤러로서의 역할을 피하기 위해 이제 유일한 옵션은 스마트 구성 요소를 통해 논리를 라우팅하고 ActionCreators를 사용하여 UI에 대한 직접 응답으로 논리의 초기 단계를 실행하는 것입니다. 실제 첫 번째 결정은 Redux.state 및 / 또는 구성 요소의 로컬 상태를 기반으로하는 스마트 구성 요소에서 이루어집니다.

범주를 삭제하고 webapi를 사용하여 응답으로 다른 항목을 새로 고치거나 삭제하는 이전 예제의이 접근 방식은 좋지 않습니다. 개발 환경 설정에 따라 서로 다른 기술의 혼합으로 이어질 것이라고 가정합니다. AC, 감속기, 스마트 구성 요소에 있어야합니까? 패턴이 어떻게 진화하는지 보겠습니다.

나는 비동기 호출을 상점에서 멀리하기 위해 포인트를 구입했습니다. 그러나 나는 그것이 타당하다고 생각하지 않습니다. 왜냐하면 그것은 다른 곳에서 복잡성을 상당히 증가시키기 때문입니다. 반면에 스토어 / 리듀서에서 비동기 기능을 사용하는 것은 거기에서 실행하고 디스패치하거나 순수한 접근 방식으로 이러한 기능을 데이터로 처리하고 먼 곳에서 트리거하는 한 그다지 복잡하지 않습니다.

액터는 비슷하게 비동기를 실행하고 다른 액터에게 메시지 (액션 객체)를 보내거나 FSM에서 계속하기 위해 자신에게 보낼 수 있습니다.

여기에 조치 할 수있는 것이없는 것 같아서 닫습니다. 비동기 작업 문서는 대부분의 질문에 답해야합니다. 더 많은 이론적 논의는 우리가 실행할 수있는 실제 코드 없이는 나에게 가치있는 것 같지 않습니다. ;-)

@gaearon redux를 사용하는 예제 중 하나에 API 호출을 처리하는 올바른 방법을 구현하는 실제 코드를 추가 할 수 있습니까 (미들웨어를 사용하는 "실제"예제 외부)?

모든 문서와이 문제를 몇 번 읽은 후에도 실제 배치에 대한 질문이 있습니다. 이러한 부작용을 배치 할 파일을 이해하는 데 문제가 있습니다 https://github.com/rackt/redux/issues/291#issuecomment -123010379 . 이 이슈 스레드의 "올바른"예라고 생각합니다.

이 영역에 대한 설명에 미리 감사드립니다.

불순한 액션 크리에이터에 대한 중요한 생각을 말씀 드리고 싶습니다.

액션 생성자에게 비동기 호출을 넣거나 일반적으로 불순한 액션 생성자를 갖는 것은 나에게 큰 단점이 있습니다. 애플리케이션의 제어 로직을 완전히 스와핑하는 것이 단순히 스토어를 스와핑하는 것만 큼 간단하지 않은 방식으로 제어 로직을 조각화합니다. 창조자. 나는 항상 비동기 프로세스에 미들웨어를 사용하고 불순한 액션 생성자를 완전히 피하려고합니다.

내가 개발중인 앱에는 적어도 두 가지 버전이 있습니다. 하나는 온 사이트 Raspberry Pi에서 실행되고 다른 하나는 포털을 실행합니다. 고객이 운영하는 공개 포털 / 포털에 대해 별도의 버전이있을 수도 있습니다. 다른 API를 사용해야하는지 여부는 불확실하지만 가능한 한 그 가능성에 대비하고 싶습니다. 미들웨어를 사용하면 그렇게 할 수 있습니다.

그리고 나에게 API 호출을 액션 생성자에게 분산시키는 개념은 상태 업데이트에 대한 중앙 집중식 제어라는 Redux 개념과 완전히 반대됩니다. 물론, API 요청이 백그라운드에서 실행되고 있다는 단순한 사실은 Redux 스토어 상태의 일부가 아니지만, 그럼에도 불구하고 정확한 제어를 원하는 것은 여전히 ​​애플리케이션 상태입니다. 그리고 Redux 저장소 / 감소 기와 마찬가지로 제어가 분산이 아닌 중앙 집중화 될 때 가장 정밀하게 제어 할 수 있습니다.

@ jedwards1211 https://github.com/redux-effects/redux-effects 에 관심이있을 수 있습니다. 아직 확인하지 않은 경우와 # 569에서 논의 할 수 있습니다.

@gaearon 쿨, 지적 해 주셔서 감사합니다! 어쨌든 내 미들웨어를 사용하는 것은 지금까지 그리 어렵지 않았습니다. :)

나는 Elm과 같은 접근 방식을 만들었습니다 : redux-side-effect . README 는 접근 방식을 설명하고 대안과 비교합니다.

@gregwebs 나는 redux-side-effect 좋아하지만 스왑 가능한 제어 로직도 어색 할 것입니다. 왜냐하면 여러 다른 저장소 구성자가있을 때 sideEffect 함수를 내 감속기 모듈로 가져 오는 방법에 대한 질문이 있기 때문입니다. 다른 빌드에서 사용할 모듈.

그래도 재미있는 해킹을 사용할 수 있습니다. state 자체에 sideEffect 만 저장하면 감속기에서 자동으로 사용할 수 있습니다! : stuck_out_tongue_winking_eye :

https://github.com/rackt/redux/pull/569/ 와 같은 것은 내가 작업하려는 방식에 이상적에 가깝지만 물론 표준 부품이 아닌 한 프로덕션 프로젝트에서 사용하고 싶지 않습니다. API의.

여기에 아이디어가 있습니다. 미들웨어가 액션에 sideEffect 함수를 붙입니다. 약간 해키하지만 감속기가 비동기 코드를 시작할 수 있도록 만드는 데 필요한 가장 작은 변경 사항 :

sideEffectMiddleware.js :

export default store => next => action => {
  let sideEffects = [];
  action.sideEffect = callback => sideEffects.push(callback);
  let result = next(action);
  sideEffects.forEach(sideEffect => sideEffect(store));
  return result;
};

간단한 sideEffect 접근 방식에는 여러 가지 방법이 있습니다. 변형을 시도하고 다시보고하십시오.

위의 sideEffectMiddleware 접근 방식을 사용하도록 코드를 리팩터링했으며 결과 코드 구성이 정말 마음에 듭니다. sideEffect 함수를 내 리듀서로 가져올 필요가없는 것이 좋습니다. action 됩니다.

@ jedwards1211 패키지 버전 2.1.0에서 코드를 actionSideEffectMiddleware 로 게시했습니다.

@gregwebs 멋지다! 저를 공동 작업자로 등록 하시겠습니까?

@ jedwards1211 당신이 추가되었습니다. 아마 당신은 적절한 재생 지원을 추가 할 것입니다. :) 나는 이것을 사용하는 곳에서 아직 그것을 이용할 수 없습니다.

@gaearon 기록하고 재생 한 액션은 미들웨어를 전혀 거치지 않는 거죠?

그들은 기록 될 때 이미 평범한 객체이기 때문에 미들웨어는 일반적으로 개입하지 않습니다.

@gaearon 흠. 그래서 실제로 그 기능을 사용 해본 적은 없지만 ... 부작용 미들웨어가 녹음 / 재생도 깨뜨릴 것 같네요? 예를 들어 redux-effects-fetch 를 사용하면 일반 객체 FETCH 작업에 대해 여전히 ajax 요청을 수행합니다.

function fetchMiddleware ({dispatch, getState}) {
  return next => action =>
    action.type === 'FETCH'
      ? fetch(action.payload.url, action.payload.params).then(checkStatus).then(deserialize, deserialize)
      : next(action)
}

레코더가 FETCH 작업의 steps 에서 [success, failure] 콜백을 정리하면 redux-effects 미들웨어는 상태 변경 작업을 전달하지 않지만 여전히 원하지 않습니다. ajax 요청을 트리거하기 위해 재생합니다.

redux-logger 와 같은 "순수한"미들웨어 (추가 작업을 전달하지 않는)를 "순수한"미들웨어 (작업을 전달할 수 있음)와 분리하는 방법이 있습니까?

안타깝게도 redux-effects 면밀히 조사하지 않아 귀하의 질문에 답변 할 수 없습니다.

문제 없습니다. 어떤 경우에도 레코더는 미들웨어가 부작용을 수행할지 여부를 결정하는 데 사용할 수있는 작업에 플래그를 추가합니까? 내 미들웨어에서 devtools를 올바르게 지원할 수있는 방법을 찾으려고합니다.

그렇지 않습니다. 인핸서 컴포지션 체인에 devTools() _after_ applyMiddleware 를 넣어야하므로 액션에 도달 할 때까지 추가 해석이 필요없는 "최종"액션이됩니다.

아, 알겠습니다. 미들웨어가 부작용을 수행 한 후에는 작업에서 필드를 제거하거나 재생시 미들웨어를 통해 되돌아 갈 때 부작용이 발생하지 않도록 조정하면됩니다. 개발 도구로 작업하지?

네, 좋은 방법 인 것 같습니다.

깨달음을 주셔서 감사합니다!

@gaearon @vladar @ jedwards1211 https://github.com/salsita/redux-side-effects에 관심이있을 수 있습니다 (state, action) => (state, sideEffects) 의 구현이지만 리듀서가 튜플을 반환하는 대신 (이미 발견 한 것은 불가능 함) 효과를 산출합니다.
나는 곧 그것을 가지고 놀았고, 핫 리로드와 리플레이는 괜찮은 것 같습니다. 지금까지 redux 기능이 손상되지는 않았지만 고위 reduxer 중 일부가 뭔가를 찾을 수 있습니다. :)
나에게 이것은 로직이 주로 리듀서에 있도록하여 효과 (현재 상태에만 의존하지 않는 전환 동작)를 외부 서비스에 위임하는 효과적이고 테스트 가능한 상태 머신으로 만드는 리덕스 스택에 정말 중요한 추가로 보입니다. Elm 아키텍처, 효과 및 서비스와 매우 비슷합니다.

또 다른 접근법은 redux-saga 로 제너레이터도 사용하지만 리듀서와 부작용을 별도로 유지합니다.

나는 의미 @minedeljkovic 생각 @gaearon

나에게 이것은 로직이 주로 리듀서에 있도록하여 효과 (현재 상태에만 의존하지 않는 전환 동작)를 외부 서비스에 위임하는 효과적이고 테스트 가능한 상태 머신으로 만드는 리덕스 스택에 정말 중요한 추가로 보입니다. Elm 아키텍처, 효과 및 서비스와 매우 비슷합니다.

https://github.com/yelouafi/redux-saga/ 는 기존의 접근 방식에 비해 가장 큰 장점입니다. 왜냐하면 redux-thunk 작동 방식과 매우 유사하기 때문입니다. .

반면에 https://github.com/salsita/redux-side-effects 는 Elm 아키텍처와 비슷합니다.

예, redux-saga 및 redux-side-effects는 생성기를 사용하여 부작용을 선언하고 sagas와 reducer를 각각 순수하게 유지합니다. 비슷합니다.

감속기에서 선호하는 두 가지 이유 :

1. 효과를 선언하는 방법에 영향을 미칠 수있는 현재 상태에 대한 명시 적 액세스 권한이 있습니다 (이 논의 중 @vladar 의 요점 중 하나라고 생각합니다).
2. 새로운 개념이 도입되지 않았습니다 (redux-saga의 Saga)

https://github.com/rackt/redux/issues/1139#issuecomment -165419770의 내 의견은 redux-saga 해결되지 않고 모델을 수락하는 것 외에는 해결할 수있는 다른 방법이 없기 때문에 여전히 유효합니다. Elm 아키텍처에서 사용됩니다.

redux-side-effects에 대한 내 요점을 강조하려는 간단한 요점을 넣었습니다 : https://gist.github.com/minedeljkovic/7347c0b528110889aa50

나는 단지 "실제 세계"라고 생각하는 가장 간단한 시나리오를 정의하려고 노력했지만 여전히이 논의의 몇 가지 요점을 강조합니다.

시나리오는 다음과 같습니다.
응용 프로그램에는 개인 사용자 데이터를 입력해야하는 "사용자 등록"부분이 있습니다. 다른 개인 데이터 중에서 출생 국가는 국가 목록에서 선택됩니다. 사용자가 국가를 선택하고 선택을 확인하거나 취소 할 수있는 "국가 선택"대화 상자에서 선택이 수행됩니다. 사용자가 선택을 확인하려고하지만 국가가 선택되지 않은 경우 경고를 받아야합니다.

아키텍처 제약 :

1. CountrySelection 기능은 모듈 식이어야합니다 ( redux ducks 의 정신). 따라서 응용 프로그램의 여러 부분에서 재사용 할 수 있습니다 (예 : 생산 국가를 입력해야하는 응용 프로그램의 "제품 관리"부분에서도).
2. CountrySelection의 상태 슬라이스는 전역 (redux 상태의 루트에 있음)으로 간주되어서는 안되지만이를 호출하는 모듈 (및 해당 모듈에 의해 제어 됨)에 대해 로컬이어야합니다.
3. 이 기능의 핵심 로직은 가능한 한 적은 움직이는 부분을 포함해야합니다 (내 요점에서이 핵심 로직은 감속기에서만 구현됩니다 (그리고 로직의 가장 중요한 부분 만). 모든 redux 구동 구성 요소가해야하므로 구성 요소는 사소해야합니다. 수 :). 그들의 유일한 책임은 현재 상태를 렌더링하고 조치를 보내는 것입니다.)

이 대화와 관련하여 요점에서 가장 중요한 부분은 countrySelection 감속기가 CONFIRM_SELECTION 작업을 처리하는 방식에 있습니다.

@gaearon , 나는 표준 redux에 추가 된 redux-side-effects가 constratints를 고려하여 가장 간단한 솔루션을 제공한다는 내 진술에 대한 귀하의 의견을 대부분 평가할 것입니다.

이 시나리오의 구현을위한 가능한 대안 아이디어 (redux-side-effects를 사용하지 않고 redux-saga, redux-thunk 또는 다른 방법을 사용)도 매우 적절할 것입니다.

@ tomkis1 , 나는 여기에서 귀하의 의견을

(이 요점 https://gist.github.com/minedeljkovic/9d4495c7ac5203def688에는 약간 다른 구현이 있습니다. 여기서 globalActions는 피합니다.이 주제에는 중요하지 않지만 누군가이 패턴에 대해 의견을 말하고 싶을 수도 있습니다.)

@minedeljkovic 요점에 감사드립니다. 나는 당신의 예에서 하나의 개념적 문제를 봅니다. redux-side-effects 은 부작용에만 사용됩니다. 그러나 귀하의 예에는 부작용이 없지만 장기적인 비즈니스 거래가 있으므로 redux-saga 가 훨씬 더 적합합니다. @slorber 와 @yelouafi 는 이것에 대해 더 많은 것을

즉, 저에게 가장 우려되는 문제는 리듀서 (https://github.com/salsita/redux-side-effects/pull/9#issuecomment-165475991) 내에서 새로운 작업의 동기식 dispatching 입니다.

yield dispatch => dispatch({type: COUNTRY_SELECTION_SUCCESS, payload: state.selectedCountryId});

@slorber 는 "비즈니스 부작용"이라는 용어와 함께 왔으며 이것이 바로 귀하의 경우입니다. redux-saga 은이 특정 문제를 해결하는 데 빛을 발합니다.

@mindjuice 저는 귀하의 예제를 완벽하게 이해하지는 못하지만 여기에 준 온 보딩 예제가 마음에 듭니다 : https://github.com/paldepind/functional-frontend-architecture/issues/20#issuecomment -162822909

saga 패턴은 또한 일부 암시적인 것을 명시 적으로 만들 수 있습니다.
예를 들어 작업을 실행하여 발생한 일을 설명하고 (나는 이벤트가 과거 시제 여야하므로 이벤트를 선호 함) 일부 비즈니스 규칙이 시작되고 UI를 업데이트합니다. 귀하의 경우 오류 표시는 암시 적입니다. 무용담을 통해 확인시 국가가 선택되지 않은 경우 "NO_COUNTRY_SELECTED_ERROR_DISPLAYED"또는 이와 유사한 작업을 전달할 수 있습니다. 나는 그것이 완전히 명시적인 것을 선호합니다.

또한 사가를 오리 사이의 연결 지점으로 볼 수 있습니다.
예를 들어 duck1과 duck2가 있고 각각에 대한 로컬 작업이 있습니다. 두 마리의 오리를 연결하는 아이디어가 마음에 들지 않으면 (한 마리의 오리가 두 번째 오리의 작업 생성자를 사용한다는 뜻입니다) 무슨 일이 일어 났는지 설명하도록 한 다음 두 오리 사이에 복잡한 비즈니스 규칙을 연결하는 Saga를 만들 수 있습니다. 오리 2 마리.

Sooooo, 그것은 엄청나게 긴 스레드이며 아직 문제에 대한 해결책이 있습니까?

비동기 action() 있고 코드가 오류를 나타내거나 결과를 표시해야한다고 가정합니다.

첫 번째 접근 방식은 다음과 같이 만드는 것이 었습니다.

// the action call
action().then(dispatch(SUCCESS)).catch(dispatch(FAILURE))

// the reducer
case SUCCESS:
    state.succeeded = true
    alert('Success')

case FAILURE:
    state.succeeded = false
    alert('Failure')

그러나 이제 감속기에 "부작용"이 포함되어 있기 때문에 Redux 방식이 아닙니다 (그게 무슨 뜻인지 모르겠습니다).
간단히 말해서, 올바른 방법은이 alert() 감속기에서 어딘가로 옮기는 것입니다.

어딘가에 action 를 호출하는 React 컴포넌트가 될 수 있습니다.
이제 내 코드는 다음과 같습니다.

// the reducer
case SUCCESS:
    state.succeeded = true

case FAILURE:
    state.succeeded = false

// the React component
on_click: function()
{
    action().then
    ({
        dispatch(SUCCESS)

        alert('Success')
        // do something else. maybe call another action
    })
    .catch
    ({
        dispatch(FAILURE)

        alert('Failure')
        // do something else. maybe call another action
    })
}

이제 이것이 올바른 방법입니까?
아니면 더 조사하고 타사 라이브러리를 적용해야합니까?

Redux는 전혀 간단하지 않습니다. 실제 앱의 경우 이해하기 쉽지 않습니다. 올바른 방법을 보여주는 표준 예제로 샘플 실제 앱 저장소가 필요합니다.

@ halt-hammerzeit Redux 자체는 매우 간단합니다. 혼란스러운 단편화는 Redux를 사용할 때 리듀서의 부작용을 통합 / 분리하는 것에 대한 다양한 요구 또는 의견에서 비롯됩니다.

또한 단편화는 Redux로 원하는대로 부작용을 수행하는 것이 실제로 그렇게 어렵지 않다는 사실에서 비롯됩니다. 기본 부작용 미들웨어를 롤링하는 데 약 10 줄의 코드 만 필요했습니다. 그러므로 자유를 받아들이고 "올바른"방법에 대해 걱정하지 마십시오.

@ jedwards1211 "Redux 자체"는 가치 나 의미가 없으며 Flux 개발자의 일상적인 문제를 해결하는 것이 주 목적이기 때문에 의미가 없습니다. 그것은 AJAX, 아름다운 애니메이션 및 기타 모든 _ 평범하고 기대되는 _ 것들을 의미합니다.

@ halt-hammerzeit 거기에 요점이 있습니다. Redux는 확실히 대부분의 사람들이 상태 업데이트를 관리하는 방법에 동의하도록 의도 한 것처럼 보이므로 대부분의 사람들이 부작용을 수행하는 방법에 동의하지 않은 것은 부끄러운 일입니다.

저장소에서 "examples"폴더를 보셨습니까?

부작용을 수행하는 여러 가지 방법이 있지만 일반적으로 권장 사항은 모든 예에서와 같이 Redux 외부 또는 액션 제작자 내부에서 수행하는 것입니다.

네, 알아요 ... 내 말은이 스레드가 부작용을 수행하는 가장 좋은 방법에 대한 (적어도 여기 사람들 사이에서) 합의의 부족을 설명했다는 것입니다.

아마도 대부분의 사용자는 썽크 액션 제작자를 사용하고 우리는 그저 이상 치일뿐입니다.

^ 그가 말한 것.

나는 모든 위대한 마음이 하나의 의로운 해결책에 동의하는 것을 선호합니다
9000 개의 화면을 읽을 필요가 없도록 돌에 새겨서
실

2016 년 1 월 7 일 목요일에 Andy Edwards [email protected] 은 다음과 같이 썼습니다.

예, 알아요 ... 내가 말하고자하는 것은이 스레드가
측면을 수행하는 가장 좋은 방법에 대한 합의 (적어도 여기 사람들 사이에서)
효과.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rackt/redux/issues/291#issuecomment -169751432.

그래서, 현재 합의 된 해결책은 모든 것을 행동으로 옮기는 것입니다.
제작자. 이 접근 방식을 시도해보고 결함이 발견되면
여기에 다시 게시하겠습니다.

2016 년 1 월 7 일 목요일에 Николай Кучумов [email protected] 은 다음과 같이 썼습니다.

^ 그가 말한 것.

나는 모든 위대한 마음이 하나의 의로운 해결책에 동의하는 것을 선호합니다
9000 개의 화면을 읽을 필요가 없도록 돌에 새겨서
실

2016 년 1 월 7 일 목요일, Andy Edwards < [email protected]
<_e i = "16">

예, 알아요 ... 내가 말하고자하는 것은이 스레드가
측면을 수행하는 가장 좋은 방법에 대한 합의 (적어도 여기 사람들 사이에서)
효과.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rackt/redux/issues/291#issuecomment -169751432.

Redux 사용자의 1 %가 부작용에 대해 더 강력하고 순수하며 선언적인 솔루션을 찾고 싶어하기 때문에 이와 유사한 스레드가 존재합니다. 아무도 동의하지 않는다는 인상을받지 마십시오. 침묵하는 대다수는 생각과 약속을 사용하며 대부분이 접근 방식에 만족합니다. 그러나 다른 기술과 마찬가지로 단점과 장단점이 있습니다. 복잡한 비동기 논리가있는 경우 Redux를 삭제하고 대신 Rx를 탐색 할 수 있습니다. Redux 패턴은 Rx에서 쉽게 표현할 수 있습니다.

알았어 고마워

2016 년 1 월 7 일 목요일에 Dan Abramov [email protected] 은 다음과 같이 썼습니다.

Redux 사용자의 1 %가 찾고 싶어하기 때문에 이와 유사한 스레드가 존재합니다.
부작용에 대한보다 강력하고 순수하며 선언적인 솔루션입니다. 제발 하지마
아무도 동의 할 수 없다는 인상을받습니다. 침묵하는 대다수는
생각하고 약속하며 대부분이 접근 방식에 만족합니다. 하지만 어떤
기술에는 단점과 장단점이 있습니다. 복잡한 비동기 논리가있는 경우
Redux를 삭제하고 대신 Rx를 탐색 할 수 있습니다. Redux 패턴은
Rx에서 쉽게 표현할 수 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rackt/redux/issues/291#issuecomment -169761410.

@gaearon 네, 맞아요. 그리고 Redux가 우리의 다양한 접근 방식을 모두 수용 할 수있을만큼 유연하다는 점에 감사드립니다!

내가 REDUX-사가 REDUX-썽크보다 더 좋을 수 있습니다 이유를 설명 곳 @ 중단-hammerzeit 여기에 내 대답을 살펴 : http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for- async-flow-in-redux / 34599594

@gaearon 그건 그렇고, stackoverflow에 대한 답변은 문서와 동일한 결함이 있습니다-가장 간단한 경우를 다룹니다
http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34599594#34599594
실제 애플리케이션은 AJAX를 통해 데이터를 가져 오는 것 이상으로 빠르게 진행됩니다. 또한 오류를 처리하고 조치 호출의 출력에 따라 일부 조치를 수행해야합니다.
귀하의 조언은 다른 이벤트 dispatch 대한 것입니다.
그러면 내 코드가 사용자에게 작업 완료시 alert() 원하면 어떻게됩니까?
그 thunk 는 도움이되지 않지만 약속은 도움이됩니다.
저는 현재 간단한 약속을 사용하여 코드를 작성하고 있으며 그렇게 작동합니다.

나는 redux-saga 대한 인접한 의견을 읽었습니다.
그것이 무엇을하는지 이해하지 못했습니다.
나는 monads 별로 관심이없고, thunk 가 뭔지 아직도 모르겠고, 그 이상한 단어를 처음부터 좋아하지 않습니다.

그래서 저는 React 컴포넌트에서 Promise를 계속 사용합니다.

문서 전반에 걸쳐 썽크에서 약속을 반환하는 것이 좋습니다.

@gaearon 네, 그게 제가 말하는 것입니다 : on_click() { dispatch(load_stuff()).then(show_modal('done')) }
그렇게 할 것입니다.

아직도 뭔가 빠진 것 같아요.
redux-thunk의 README를 참조하십시오.
"컴포지션"섹션에서 썽크 액션 생성자를 연결하는 방법을 보여줍니다.

@gaearon 네, 정확히 제가하는 일입니다.

store.dispatch(
  makeASandwichWithSecretSauce('My wife')
).then(() => {
  console.log('Done!');
});

위에서 썼던 그대로입니다.

on_click()
{
    dispatch(load_stuff())
        .then(() => show_modal('done'))
        .catch(() => show_error('not done'))
}

README 섹션은 잘 작성되어 있습니다.

아니, 내 말이 아니야. makeSandwichesForEverybody 살펴보세요. 다른 썽크 액션 제작자를 부르는 썽크 액션 제작자입니다. 이것이 컴포넌트에 모든 것을 넣을 필요가없는 이유입니다. 이에 대한 자세한 내용은이 저장소의 async 예제를 참조하십시오.

@gaearon 하지만 내 멋진 애니메이션 코드를 액션 제작자에게 넣는 것은 적절하지 않을 것이라고 생각합니다.
이 예를 고려하십시오.

button_on_click()
{
    this.props.dispatch(load_stuff())
        .then(() =>
        {
                const modal = ReactDOM.getDOMNode(this.refs.modal)
                jQuery(modal).fancy_animation(1200 /* ms */)
                setTimeout(() => jQuery.animate(modal, { background: 'red' }), 1500 /* ms */)
        })
        .catch(() =>
        {
                alert('Failed to bypass the root mainframe protocol to override the function call on the hyperthread's secondary firewall')
        })
}

올바른 방법으로 어떻게 다시 작성 하시겠습니까?

@ halt-hammerzeit 당신은 actionCreator가 프라 미스를 반환하도록하여 컴포넌트가 로컬 컴포넌트 상태를 사용하여 스피너 등을 보여줄 수 있도록 할 수 있습니다.

그렇지 않으면 복잡한 타이머를 관리하여 redux-saga로 애니메이션을 구동 할 수 있습니다.

이 블로그 게시물을 살펴보십시오 : http://jaysoo.ca/2016/01/03/managing-processes-in-redux-using-sagas/

아,이 경우 구성 요소에 보관하는 것이 좋습니다.
(참고 : 일반적으로 React에서는 jQuery를 사용하여 명령 적으로 모달을 표시하는 것보다 선언적 모델을 모든 것에 사용하는 것이 가장 좋습니다.하지만 큰 문제는 아닙니다.)

@slorber 예, 저는 이미 "thunks"(또는 당신이 부르는 모든 것, 음,이 이상한 단어가 마음에 들지 않음)에서 약속과 물건을 반환하고 있으므로 스피너 등을 처리 할 수 ​​있습니다.

@gaearon 좋아, 내가 잡았다. 이상적인 기계 세계에서는 물론 선언적 프로그래밍 모델 내부에 머물 수 있지만 현실은 기계의 관점에서 비합리적인 요구를 가지고 있습니다. 사람들은 순수한 0과 1로 작동하는 비이성적 인 존재이며 비합리적인 작업을 수행하기 위해 코드의 아름다움과 순수성을 손상시켜야합니다.

이 스레드의 지원에 만족합니다. 내 의심은 이제 해결 된 것 같다.

관련 새 토론 : https://github.com/reactjs/redux/issues/1528

@gaearon 매우 멋진 설명! : 트로피 : 감사합니다 : +1 :