Please enable JavaScript.

Coggle requires JavaScript to display documents.

Business logic within Redux (Business logic might be implemented in…

- - - - simple and focused code, not much additional ceremony
    - - No easy way to cancel pending requests or only take the latest if multiple requests are made
      - No access to the global state to make decisions with. You only have access to whatever props or component state that you pass in. This might mean requiring extra data to be provided to a component that normally wouldn’t be needed for rendering but is solely needed for the business logic. Any time the business logic changes it might require new additional data to be passed down possibly affecting many components in the process
      - No interception. I also have no easy way to create business logic that applies across many actions, so if I wanted to augment all actions to have a timestamp or unique ID, I’d have to include a call to that code in all action creators
      - Testing components and fat action creators may require running the code (possibly mocked)
  - - - It's easy to perform some logic inside of the reducer
      - Business logic can choose whether to apply the state change
    - - Combines the business logic with the state updates
      - Only synchronous tasks
      - No ability to replace or dispatch a different error action
      - Access is limited to partial state if reducers are being combined
      - No global interceptions of actions
  - - - Simple and focused
      - access global state easily
      - Slightly simpler redux mapDispatchToProps for binding action creators
    - - No easy way to cancel pending requests or only take the latest if multiple requests are made
      - No interception. I also have no easy way to create business logic that applies across many actions, so if I wanted to augment all actions to have a timestamp or unique ID, I’d have to include a call to that code in all action creators
      - Testing components and thunked action creators may require running the code (possibly mocked). When you have a thunk (function or promise) you don’t know what it does unless you execute it
  - - - ES6 generators allow for limiting and cancellation
      - Action creators now only dispatch simple objects so testing components is easy. Generator code can be tested independently
      - Asynchronous orchestration looks like synchronous code via yield
    - - ES6 generators are not commonly well understood by many developers
      - Fair amount of code to setup watch loops and implement cancellation
      - No interception — sagas always run after actions have been given to the reducers
  - - - Full power
    - - All custom code — you implement all functionality
      - No safety net, if your code errors, it could stop all future actions
      - Remember to pass on actions that you aren’t concerned with
      - Need to mock things to test your code