I don't understand why we need Flux with React as React itself let's us maintain the state of the application. Every component has an initial state and the state can be changed by user actions or any other asynchronous JavaScript.
Why is React called as only a view library when it can let's us define state of the application and also update view whenever state changes. This is not what a view does....its what complete MVC does right?
For example: here is an Todo app build only with React and here is an Todo app build with Flux and React.
If we can build the Todo app with React only then why do we need Flux?
In theory you don't need flux.
In small applications you don't need flux for sure.
But what if your application consist of hundreds components? And one of your component is form. User populate this form and you send its content to server. And get response from server with new data.
And assume that this response data and data from form are necessary to other components.
Without flux:
You can move your data to root component and then distribute it down to all components. But if you need to distribute data from many other components too? This makes your application very complex.
with flux:
You move your data to stores, and all components which are interested about this data, can get it from there. You have better control on your application and source data.
I prefer redux (only one store and one source of truth)
edit:
Why is React called as a view library even if it can handle application state?
MVC is a software architectural pattern. It divides a given software application into three interconnected parts (models, views, controllers).
If we think about react and MVC it fit as View. But this is nothing wrong. It doesn't mean that you can use it only for views. It allows you to create normal applications.
But in other hand you can use it as view for other frameworks (for example you can use it with angular).
In other words it is very flexible library for many uses.
You don't NEED Flux the same you don't need MVC. They are both architectures and you can of course build something without using either.
Would you build a non-MVC app in 2016? Probably not, that doesn't mean that people didn't do it in the past.
Flux is awesome! But as most things in the tech industry is not always the right decision, things vary in a project requirement basis.
Probably the biggest selling point of Flux is that it tries to enforce the data flow in one direction, this means that you know for sure where the data is coming from. In a non-flux app the data for a component could be an own property, a property passed down the component tree, a local state variable, a state variable result of calling an API.
With Flux: "where does the data come from?". Answer: from the stores. Redux takes this further and only uses a single store.
Flux has been criticized because you need a lot of boilerplate code but again is a matter of tradeoffs.
At the end is always your call depending on your project needs.
Related
Can somebody explain to me why you would ever use a statemanagement tool like Redux or the Provider library instead of just creating your own Singleton class to hold the state of your application?
Redux is so much more than a singleton. It gives you pub/sub, time-traveling to prior states (especially good for debugging) and an open-ended api to plug in your own functionality. It is an especially good place to handle side effects.
In react, you can't just "plug in" your own data structure and expect everything to update properly. React updates on an as-needed basis. In order to do that, you have to use the React api in one form or another (context api, hooks, etc.).
Any singleton implementation you do will essentially be a subset of redux's functionality. In an overwhelming majority of cases, you will need all of redux's features (along with 3rd party middlewares) in a long-term production application.
Trying to understand the best practice for React/React Native state. Coming from the Java world, I tend to follow MVC/MVVM in my applications, but reading about other approaches makes me wonder if I am designing my application properly.
Premise:
App mostly for consuming video and audio content, storing user statistics and progress
React Native Firebase from invertase.io
Redux used for storing data structure from Firebase Realtime Database
My current approach:
If a React Component needs data, it gets it via Redux or parent component via props.
If a component needs to manipulate/fetch more data, I have separate viewmodel classes (Typescript files with no dependency to React/RN) that are accessed in a component.
If the viewmodel gets new data from somewhere, the component state gets it via Observer pattern by implementing an interface
If data needs to be persisted to Redux and/or Firebase, the viewmodel does it. I pass the Store object from the component
Approach I read/heard/discussed:
All data from/to components is received/sent through Redux
All data manipulations are done in Redux Actions
No separate controllers/viewmodels
I don't have too much history with React Native, so I am trying to understand whether the latter approach is actually superior for some reason.
These talks helped me understand Flux at a fundamental level. The basic idea is unidirectional data flow. Watch the talks and pay attention to them.
You don't need Redux to implement Flux– I used Alt.js instead.
React app Scenario
I have 2 views, UserLister and UserViewer. Both are at different urls. UserLister is a complex table (third party using ag-Grid), with fields, and sort and filtering. UserViewer is an exceedingly complex view with a ton of functionality that takes a while to load up. I want to make it really performant and user friendly to navigate back to UserLister after viewing an individual User. I want it to display all the same sorts and the same information as the user has set up.
To put it another way:
I want the changes that I (or any person) uses on listing page 1 to be available if someone navigates away and then directly back.
Idiomatic way to accomplish this?
How can I accomplish this best in react? is there some function of react-router that would apply here? I would prefer not to have to manage the ?100s? of different states that the UserLister has for sorting/filtering/selecting data manually.
React-router is routing library which manages browser history. You need another tool to save and share state between components. The idea is to make both UserLister and UserViewer to store and access information from some kind of global storage. So each time user enters specific Route data persists.
There are plenty of ways how to do that. Most idiomatic way is to use useReducer hook and then implement "vanilla" Flux architecture (aka unidirectional data flow) in your app.
If you don't want to write all boilerplate by yourself (no judgement here), you can look at Redux, which will do most background work for you.
Redux still requires some good amount of boilerplating. If you don't like it and feel more like streams and observables guy, you can use MobX, which implements reactive programming patterns for state management.
I'm very new to ReactJS and Redux (but not development, in general). I'm trying to determine how best to approach a SPA I'm building.
My app will download datasets via API and display them in a spreadsheet. I'd like to use Redux to store the data. Is that the right approach? We could potentially be looking at very large datasets. Would it be more appropriate to only store the data that is currently rendered in the spreadsheet?
I'm totally lost as to an approach that would be efficient in terms of rendering speed and memory management as well as mindful of potential network issues as rows of data are requested from the API.
Thanks...
When you are working on a react/redux app, you generally will have two options to store your state: local component state or in redux. There are quite a few blog posts out there detailing when each is appropriate. This github issue comment from Dan Abramov, one of the creators of Redux, pretty succinctly sums it up
Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. For example, a toggle in some UI element, a form input state. Use Redux for state that matters globally or is mutated in complex ways. For example, cached users, or a post draft.
Sometimes you'll want to move from Redux state to React state (when storing something in Redux gets awkward) or the other way around (when more components need to have access to some state that used to be local).
The rule of thumb is: do whatever is less awkward.
Both component state and redux state can be used performantly, so I wouldn't worry too much about that when choosing. From what you've described, the questions I would ask are
Do I need to have multiple spreadsheets of data loaded, but not all displayed at once? For instance, maybe you have multiple tabs of spreadsheets and you want to be able to tab through them without having to re-fetch the data each time
Do I need access to the spreadsheet data in a lot of different places, or is it fairly localized?
Will I be able to modify the data in the spreadsheet, and if so, how difficult would it be to perform those modifications using redux and without?
There are quite probably other considerations as well. In general, the advice given is to stick with just using React local component state until it starts feeling awkward, and then move to redux at that point. Oftentimes, components state is all you need, and if not you'll get a better appreciation for situations where redux helps.
I want to know if there is a NoSQL library or framework stack for React.js just like Angular and MongoDB. I dont really understand flux. So any comment will be helpful. Thank you.
flux is an application state container. Not something like mongoDB.
Flux lets you have an application wide state, not dissimilar to react component state.
mongoDB is a DB that persists. Only data that defines current application state should go into the flux store. It does NOT persist.
Application state example
Suppose you are using react to build a game using multiple components.
React components have a uni directional flow of data from parent to child as props.
So if the child component decides to advance you to next level, all it has to do is, change the game level stored in application state and the parent component can read from the store and do the needful for new level.
Flux is basically a library that makes it easier to have an application wide state. Since the component state is limited to a single component.
There is another library that helps you manage application state called redux. http://redux.js.org/
It's easy to understand :)
PS: You can use mongoDB or Redis or any DB for that matter in your backend. Flux is not your db. Personally, I'd rather use Redis.
I believe angular is a framework. Whereas React is a library. You have the freedom to choose the technologies you want to pair it up with.