In my experience, many people have misconceptions regarding Flux as to where it's not needed. They are using it because they have a good grip on that.

In our example, we have seen that Flux has a clear way to store and update the state of your application and when it is needed, it will trigger rendering.

Many times we have heard this: "There are two sides to every coin". Likewise, Flux is also beneficial as well as harmful for your code. For example, it's beneficial to declare global states for your application. Suppose that you have to manage logged in users and you are defining the state of router and active accounts; it will be painful when you start using Flux while managing temporary or local data.

From my perspective, I would not advise using Flux just in order to manage /items/:itemIdroute related data. Instead, you can just declare it within your component and you can store it there. How is it beneficial? The answer is, it will have a dependency on your component, so when your component does not exist, it will also not exist.

For example:

export default function users(state = initialState, action) { 
    switch (action.type) { 
        case types.ADD_USER: 
            constnewId = state.users[state.users.length-1] + 1; 
            return { 
                ...state, 
                users: state.users.concat(newId), 
                usersById: { 
                    ...state.usersById, 
                    [newId]: { 
                        id: newId, 
                        name: action.name 
                    } 
                }, 
            } 
 
            case types.DELETE_USER: 
            return { 
                ...state, 
                users: state.users.filter(id => id !== action.id), 
                usersById: omit(state.usersById, action.id) 
            }     
 
            default: 
            return state; 
    } 
} 

In the preceding Redux-based reducer code, we are managing the state of the application as part of the reducers. It stores the previous state and action and returns the next state.

As we know, in SPAs, when we have to contract with state and time, it would be difficult to handgrip state over time. Here, Redux helps a lot. How? Because, in a JavaScript application, Redux handles two states: one is the data state and another is the UI state and this is a standard option for SPAs. Moreover, bear in mind that Redux can be used with AngularJS, jQuery, or React JavaScript libraries or frameworks.

Redux is a tool whereas Flux is just a pattern which you can't use via plug and play or download it. I'm not denying that Redux derives some influence from the Flux pattern but we can't say it's 100% similar to Flux.

Let's go ahead to and look at a few differences.

Redux follows three guiding principles, as follows. We will also cover some differences between Redux and Flux.

const data = normalize(response,arrayOf(schema.user)) 
state= _.merge(state,data.entities) 

In a flat state, we have the benefit of dealing with nested resources and immutable objects, along with the benefit, that a declared state cannot be modified.

The other benefit of immutable objects is that, with their reference level equality checks, we can have fabulously improved rendering performance. For example, with immutable objects there is shouldComponentUpdate:

shouldComponentUpdate(nexProps){ 
    // instead of object deep comparsion 
    returnthis.props.immutableFoo!==nexProps.immutableFoo 
} 

In JavaScript, the use of the immutability deep freeze node will help you to freeze nodes before mutation and then it will verify the results. The following code example shows the same logic:

return{ 
    ...state, 
    foo 
} 
 
return arr1.concat(arr2) 

I hope that the preceding examples have clarified Immutable.js and its benefits. It also has uncomplicated methods but it isn't much used:

import{fromJS} from 'immutable' 
 
const state =fromJS({ bar:'biz'}) 
constnewState=foo.set('bar','baz')  

From my point of view, it's a very fast and beautiful feature to use.

Quite often, I have heard people asking about the alternatives to Flux and Redux, as they want more reactive solutions. You can find some alternatives in the following list: