CODEWITHSUNDEEP
reactjsreactjs-fluxflux
Josef.B
Josef.B

Reputation: 962

React + Flux change state while executing action

I am tempted to add error data to the store. For example, 

var store = {
      error: {msg:'',info:{}},
      others: '',
      etc: ''
}

On an error in the app, an action will update the error via the dispatcher, and the error panel will be shown to the user. The render of the error panel conditionally shows the div by testing the error msg state.

On the next user input, an action, i.e., userAction, the model state will be updated by the dispatcher. Problem: the error panel will still be shown, since the error msg state was not 'reset'.

The userAction will be setting other non-error state. Flux will emit a change for this change. Yet, if I follow the Flux model, a reset of the error should also be done here, in this action, but that would cause an emit, which tells to UI to update. Seems incorrect.

My thinking is: 1. Don't put this kind of stuff in the store? Or, 2. The store will reset the error state for every non-error update of state. Or, 3. Each action will also include an error state object for any state updates.

Currently my solution is to clear the error data within the store functions:

}, function(payload){
    API.setError({msg:'',info:{}});

    switch(payload.actionType){
        case "BRANCH_SELECTED":

What is the non-idiotmatic way of doing this? I'm new to React and Flux, so I'm sure this is newbie question. I'm using McFly as Flux implementation.

Upvotes: 1

Views: 983

Answers (1)

matthias
matthias

Reputation: 2264

Though your question may have already been answered within the comments: I meditated on a similar question in my current React project and so I'm going to share my experience and outcome. I'm using fluxxor instead of McFly but that shouldn't matter here.

As flux stores should contain all application state and logic, I came to the conclusion that it's absolutely okay and in the sense of the flux architecture if you programmatically clear your error states conditionally within your store functions.

In my understanding it makes sense to keep error state handling related to a specific store within exactly that store (and therefore probably received and rendered by few listening components). As mentioned by @fisherwebdev, the store logic should determine the state of an error, specifically based on the action types it registered callback functions to. In your case, think of a BRANCH_SELECTION_ERROR type action being dispatched that causes error state to be set. On the other hand the BRANCH_SELECTED action type should always clear this state.

My concrete solution is in fact to call "private" store functions clearErrorMessages() or clearFormValidationMesssages() which simply clear state variables dependent on the actions being currently dispatched.

Global errors, i.e. errors that are somehow related to the application state like server communication timeouts, may go into some "appStore" and being updated or cleared in a comparable way. So e.g. router transitions may cause global error state to be cleared.

Upvotes: 0

Related Questions