Redux Notes

  1. Reducer should manage only a single part of the state, so if there are 2 filter objects, with same UI Component, does the same filter reducer manage both, or different. What if the actions are different for each?
    1. The presentation components can be reused, but the container component will be different for each filter, even if they host the same presentation components.
    2. This is coz the part of state they manage is different.
    3. The design would be such that there will be a filter reducer that delegates the individual filter reducers, the slice of the state that they work with.
  2. Should state be made from reducers or static json scema?
    1. It’s the same thing logically, just that one is composed of reducers and other is composed of state slices.
    2. But having the schema written down to represent the store would make it easier to refer it, coz if it’s just a bunch of reducers, then you’ll have to go into each reducer to see what state it manages and so on.
  3. A filter bar component simply fires all applied filters and in store it is simply the array that contains all filter objects…does it have it’s own reducer?
    1. The filterBar shouldn’t have a reducer coz it’s not represented in the state.
    2. Instead, the firing of filter should be done with an @Effect (Action Creator), which composes multiple functions, like making server calls, and dispatching sequence of actions etc. acting like Middleware
    3. So if we want to make server call on “APPLY_FILTER” Action that the filter’s Apply button click raises, then there’ll be a GET_TASKS Effect that listens to this action and makes the server side call and on getting the response, dispatches the UPDATE_FILTER Action, that all filters are listening to (NOTE, all filters listen to the same Actions).
    4. Also note that each filter also directly listens to “APPLY_FILTER” and closes the filter dropdown. This happens independently of the Effect that is listening to this Action.
  4. Should the Filter State Reducer be different from Items Reducer?
    1. YES, but moreover, the Items should not reside in the filter state.
    2. The Store should always be normalized, and so the items will have another table and so in the state it stays parallel to the filter.
    3. Now that the items are not a part of filter, so now filterReducer can’t update items and so itemReducer is needed for it.
    4. Note that the filter object will now have itemArray instead with itemIds which is a foreign key of the item object(table)
  5. Should whatever that can be derived from state be ALWAYS derived and NOT kept in state?
  6. Now that we are keeping local filter state in store, should it be in a different section: {userState: {}, appState: {}, routerState: {}} OR should it be merged with appState? Should the UIState be kept distinct from the Application State in the Store?
    1. NOT if it isn’t awkward. Ideally all state of the filter should be in the filter object in the store. And the filter reducers listen to all actions of the filter and puts all state in the store.
  7. Can we fire actions for stuff that doesn’t update the State and have reducers run that logic? OR does reducer always have to update some part of the State?
    1. NO, to run this kinda logic, use Action Creaters. They are implemented as @Effects in ngRx.
  8. The store is made of reducers right, so with 1 filter, I use provideStore(branchFilterReducer), but now when I create another instance of branchFilterComponent, how do I tell the store that I now have 2 filters in my store?
    1. Each filter will have it’s own reducer as each filter has different state.
    2. Also, even though the presentation components are the same, the container components of both the filters will be different
  9. convert filter types to directives?
    1. This needs to be vetted out. We can have different filter presentation components for different filter types, OR we can have a single filter presentation component whose behavior is changed by directives.
  10. Sharing Action Types
    1. If the action type every filter for “Apply Button Click” is different, then if Effect is dispatching it, it’ll have to dispatch APPLY_F1, APPLY_F2, APPLY_F3… separately BUT INSTEAD if I share the Action Type as APPLY, then its just one action to dispatch…
    2. Moreover former case above might be an issue in case the filters in the filter bar are getting added dynamically (from some externalized config). In that case the Effect doesn’t have the luxury to hard-code the separate Action dispatches.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s