I was looking into how secure a redux application can be, I am storing certain values in redux store i.e. user token etc.. and tried to see if someone else could gain access to them via an xss attack for example, I checked sessionStorage, localStorage, cookies and it is not there, as well as it is not inside my app.js file (my bundle file), hence my question.
Was just about to answer How does React and Redux store data? Is it localstorage or cookies? when it got closed as a duplicate. So I wanted to paste my answer here.
Answer
First off, it's worth noting that UI libraries don't actually manage state (other than component-level state). ReactJS and VueJS expect you to pass data to them like you would pass parameters to a function. They aren't concerned with where this data came from or how you're storing it.
Redux, on the other hand, is not a UI library -- it's a state management library. Redux does store state. The VueJS corollary to Redux would be "Vuex".
With that out of the way, the next thing you need to know is that there's a difference between state management and state persistence. Libraries like Redux and Vuex usually keep track of your variables and provide tools for changing state (reducers, specifically) - but they don't manage the persistence of that state. Persistence refers to saving the state somewhere to reload it the next time someone comes to your app - and seems to be what you're curious about (since you mentioned cookies and Local Storage)
Persistence is usually coded by hand (send the state to an API endpoint which saves it to a database, then when you reload the page you ping a different API endpoint to retrieve the state) or you utilize a plugin / module for your state manager to handle persistence for you. For example, there's a popular Redux Local Storage plugin called (trivially enough) redux-localstorage
From this part of documentation (http://redux.js.org/docs/FAQ.html#performance-state-memory) I deduce it's stored in memory, so it is not persistent.
The state in Redux is stored in memory. This means that, if you refresh the page the state gets wiped out. The state in redux is just a variable that persists in memory because it is referenced by all redux functions.
A misconception is:
In redux, we know that the state is stored as an object.
This is not correct. State in redux can be any valid JavaScript value, not just an object. It just usually makes the most sense for it to be an object (or a special object like an array) because that allows for a more flexible data structure (but you could make the state just be a number for example, according to your need).
Redux use internal memory for all data. For example, when you subscribe to Store, Redux just push listener to private array and do not use Cookies or LocalStorage.
Related
I have a question about possibilities of data pre-loading with nuxt.js
I'm currently working on a project that is strongly coupled with back-end data and I stumbled on some difficulties.
I would like to save some data in localStorage to speed up the navigation within my website, the data consist of dictionaries containing (key: value) pairs that I use to resolve item properties names that come from api calls on query for specific item. (oh and they can possibly change in the future with more languages coming)
When the localStorage wasn't initiated (first visit/storage cleared/disabled) I would like to fetch that data to Vuex store so I can use store getters in Vue components.
Some problems emerge with my approach as localStorage is available from mounted() and not before that point in components life cycle. So I can't detect if there is any cached data before the whole page is already rendered.
I would like to hear any ideas, is there any workaround, maybe this way of cashing data is simply wrong. I'm just at the beginning of front-end journey.
Sidenote - I have wrote a custom plugin for async calls to api but Nuxt renders all components before I even commit the chages to Vuex store.
So Basically, I came across many articles where they are referring to manage state via flux or redux.
I wanted to know that how about UI component having its own state? Is it good practice to let redux manage the Api call and success toast messages etc. but UI components should have their own local state?
Kindly someone elaborate what is the best practice in industry?
Though the question calls for opinion, I am going to leave my answer. There is no standard best practice regarding this. It boils down to convenience and ground rules of your team, if there are more than one people writing the code.
I use Redux quite a lot. However, I won't refrain from using local state in components.
Form handling like input onChange handlers require local state. It is not performant to use global state for onChange handlers.
Reusable component uses local state. Again, it boils down to whether the reusability is a technical reusability or business reusability. If you are developing a custom scrollbar component, use local state. However, if you are using a comment form which is used everywhere in your application, use global state.
I prefer to have most of the stuff in global state. I use redux thunk as well. In redux thunk, it is possible to access global state within the thunk function. This is quite useful as it avoids the reliance for props / context being passed all around.
I do keep some simple things in local state -- for example, show / hide some stuff. I don't mind waiting for promises to resolve before hiding some stuff using local state.
Overall, the decision to use global state vs local state is primarily based on convenience. There are no standard rules other than what you and your team are comfortable with.
React is a way to declaratively deal with UI. There are some rules of the framework like state, props, context. It is left upto the developer to make the UI declarative and performant based on these primitives. How, a developer does it does not matter as long as the code is maintainable and understood by others.
After asking many professionals and industry developers, I came to know that managing state through redux depends on your application scope.
but more importantly, If I am working on enterprise Application then the application state must be managed through redux.
Now the question is what should be kept in our redux store. well, you can store almost anything in redux store but better to manage the local state of a component as well. for instance, opening a component Boolean should be managed in local state or any string or header name etc.
Good question! The answer is usually "it depends", but there are clear cases when you'd probably prefer to use one over the other.
Use Redux for storing state relevant to the application. E.g. the current page/panel that should be shown. As you mentioned, showing a notification/message - is something that'd make sense to store in redux state, as the alternative would be passing state all over the place, e.g. an error prop bubbling up to your root component which renders the toast message. Using thunk is also a good idea when you're fetching/manipulating data relevant to the whole app, e.g. a list of things that appear in several places.
Use component state for storing state only relevant to the component. That is, if you're filling in a form, it makes sense to store the value of text inputs, checkboxes etc. in your component state (perhaps in conjunction with container and presentational components) as the values at this point aren't relevant to the rest of the application.
I have often heard questions that ' Why one should use redux whether there is also a State in the ReactJs. Which extra facilities redux does provide to the developer ? '
For small applications when there aren't a lot of components, you can do without redux. But in large applications, it becomes pretty complicated/tedious to chain props through components especially if one that is deep 6 levels needs it.
This is a great article that explains it
https://blog.logrocket.com/why-use-redux-reasons-with-clear-examples-d21bffd5835
The Redux docs page about organizing state (here), list out a few reasons one might lean to using Redux store over component state. However, they do clearly state that "using local component state is fine" and that, in the end, the developer should find the proper balance for the work at hand.
Some common rules of thumb for determining what kind of data should be put into Redux:
Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Redux is required when your application is big with many components. Redux works as global meaning if you set value in one component you can get that value across components. This is the primary advantage with state management Library.
If your application is small with 10 to 20 components then we don’t need redux. We can pass down state to child components as props but when application grows big you will have so many components and it’s very difficult to play with component level state and you won’t have control of the flow and you can’t track of values between components
So redux is very useful in such cases.
I was reading the following sources Why use Redux over Facebook Flux?, the redux documentation http://redux.js.org/docs/recipes/ServerRendering.html as well as the definition of a singleton. Could someone explain how the store being a singleton in Flux causes problems for server-side rendering using Flux architecture with react?
Singleton are classes which can be instantiated once. On client-side, each user will have its own store but on the server there will be 1 instance of the store shared for all users....where we need an instance for every request.
e.g: if i have a cart where i got only one item, on serve-side, the store will have 1 item and all users will share the store and state in it.
Here is an answer
https://discuss.reactjs.org/t/facebook-flux-singleton-store-and-server-side-rendering/5652
There's one thing about Flux (or at least about its implementations) that I don't quite understand.
It's about internal data management of Stores. I'll try to explain my question by breaking it down into points.
Let's imagine I have some app with client-side routing.
As I understood Stores are singletons. Somewhere they store some data (e.g. an array)
User clicks somewhere and navigates to some part of the app. Correspoding Store fetches some data.
Let's imagine that it's a really big amount of data. So big that it takes a lot of resources and even makes page laggy.
After a while user navigates to a different route. What happens with the internal data of the Store mentioned above?
As far as I understood, it remains intact. At least until user navigates to original route and the Store changes its state.
And before that happens the Store holds big amount of data even when it's not needed.
Can someone clear this out for me? Thanks.
Store just listen the dispatcher(actions) and somehow react on it. In example you mention - yes, it will hold the data at least you don't use weakmap or kinda, but you also can listen actions on changing routes and process your data in this case.