So we are about two months in on a project. This is the first time I have ever managed code writers and not written the code myself. I've been reading their code for the last week. What was suppose to be a simple React app has turned into a spaghetti mess.
I understand: redux helps to manage global state. But should that mean that all buttons should map to a global "action?" This has seemed to create this entire mess of objects scattered throughout the entire app. I keep asking myself, why are we using global state for everything when local state could be used for 90% of the application. This is the kind of code that gives me heartburn:
let subitems = SidebarItems[state.type].sub_items;
Store.dispatch(SidebarSubItemHandler(item.action, subitems[0], null));
if(item.sub_items[subitems[0]].param) {
browserHistory.push(`${item.sub_items[subitems[0]].path}/${item.sub_items[subitems[0]].param}`);
} else {
browserHistory.push(item.sub_items[subitems[0]].path);
}
subItembuttons = Object.keys(this.props.subitems.sub_items).map(subitem => {
let subItem = this.props.subitems.sub_items[subitem];
return <li className={this.props.activeSubItem.action == subItem.action ? "bottom-bar-item active" : "bottom-bar-item"}
onClick={e => this.props.onClickSubItem(e, subItem)}
key={subItem.action} style={this.props.subitems.inlineStyles.mobileSubItemLI}>
{subItem.item}
</li>;
});
The application is littered with all kinds of objects like these that map to "action" objects. So at this point we are making the decision to scrap the entire project and restart from scratch, but without redux. Let's try to do as much as possible using local state only. When it comes time, and we need global state for something, ONLY implement it for that something, not every single action in the app. Does this make sense?
So I guess my question is: If we develop an app using local state and just fundamental React, will we be creating un-reversable problems that would prevent us from implementing redux on a per item basis?
Quoting from the relevant Redux FAQ entry at http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state:
Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
Some common rules of thumb for determing 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)?
Per your specific question: if you use the "container component" pattern fairly consistently, it should be relatively straightforward to swap those "plain React" containers for Redux-connected containers down the line. See https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories for articles on the "container/presentational component" pattern.
Two other thoughts. First, I recently co-authored an article that discusses why you might want to use Redux in a React application.
Second: yeah, that code looks kinda ugly. I'm hoping those are at least three different snippets from different parts of the codebase, rather than one snippet, but that's rather hard to read. The repeated use of "sub_items" and "subitems" seems like a bit of a red flag, readability-wise.
It also doesn't look like it's following good Redux practices. For example, idiomatic Redux code almost never references the store directly. Instead, references to dispatch and getState are available via middleware, and thus can be used in action creators via redux-thunk and redux-saga. Connected components can also access dispatch.
Overall: you are absolutely welcome to use as much or as little Redux as you want, and as much or as little local component state as you want. I think the larger issue, though, is how well your team actually understands Redux, and how they're trying to use it.
Related
I am new to react and Redux and utilize a react project on GitHub: overcode/rovercode-ui to learn react and Redux. I have some questions about it.
For each component in fold component, I cannot find why the component has so many props. For example, for Workspace component, at the end of file \component\Workspace, it checks the props of Workspace component. I wonder where these props come from (namely where these props are defined), e.g., the code props.
Action createProgram defined in file \actions\code.js use an asynchronous POST method to create an id for newly created program. However, in the sub-reducer \reducers\code.js, when action.type equals to CREATE_PROGRAM_FULFILLED, id will be extracted from action.payload to save into global state. So, how the id is saved into the global state and action of type CREATE_PROGRAM_FULFILLED is dispatched?
Can anyone help me analze this project? Thanks a lot :)
Hello and welcome to React - Redux universe. I am sure you will love it but regardless of your background or experience level, you have to make your peace with the fact that there is a learning curve and when you are especially new to thinking in terms of components, developing a different mindset takes time. Don't worry, we all been there and it will past. Just give yourself some time.
I am afraid, even if we spend some time together to analyze this project, I don't think that it would make your life easier in terms or learning React or Redux. Analyzing this project is more like helping a beginner foreign language learner to translate a story. It might help you to understand the story, but at the end you won't probably be able to write a new story in the language you are trying to learn.
That said, I'll try to briefly provide answers to your questions and try to point out why analyzing this specific project will not be as helpful as you would expect
1) In order to comprehend where all these props come from, you need to recognize the following pattern that is
connect(mapStateToProps, mapDispatchToProps)(Workspace))
so basically, thanks to connectfunction, you can connect your component directly to the redux store (you name it as global state)
For instance, let's take a look at the following snipped from the file https://github.com/rovercode/rovercode-ui/blob/alpha/src/components/Workspace.js#L36
const mapDispatchToProps = (dispatch, { cookies }) => ({
updateJsCode: jsCode => dispatch(actionUpdateJsCode(jsCode)),
Basically, thanks to mapDispatchToProps we return an object. And since we use mapDispatchToProps as a parameter of connect function, connect function takes the properties of the returned object and passes them to component as props.
Thanks to that, in the following line https://github.com/rovercode/rovercode-ui/blob/alpha/src/components/Workspace.js#L293 we could manage to extract updateJsCode from the props
So, good news and bad news. In order to explain this to you, I need to spend some time to build a fundamental understanding of what is props, what is higher order components, what is redux, what is actions etc. etc. Once you learn the fundamentals first, it is easier to connect the dots.
2) So in order to answer this question, I need to go through the codebase to understand the architecture of the project. The important thing to be aware of is that, even though there are some certain best practices, every project has its own data structure and architecture. It is up to the creator of the projects to make a decision in terms of component architecture, data structure etc. etc. When you are new and try to understand the technology by checking existing projects, you might end up confusing yourself big time and treating the architecture of those project as source of truths.
My humble suggestion to you is, first things first, try to focus on React without Redux. Because most of the time, you might not even need a state management depending on the scope of the project (again a decision needs to be made by the team etc.)
The things that you might want to learn with React are
1) Parent-child-sibling component relationships
2) React Hook api (relatively new, but usage is increasing dramatically so as a new learner you should definitely take a look)
3) If you want to understand some "old" project and tutorials you might also want to learn about life cycle methods
4) What is presentational component vs container component
5) Higher order components
Once you are comfortable with the fundamental of React, you can then continue with Redux. I bet things will be way more easier
If you need more suggestions, send me a message so I can try to provide you some resources
Thanks for your answers. After reading your reply and learning related conceptsI, still have a question. You explain that connect(mapStateToProps, mapDispatchToProps)(Workspace)) connects component directly to the redux store and use the example to illustrate that mapDispatchToProps connects actions to component. So my understanding is mapStateToProps connects state of redux store to component. e.g., code code property of this.props comes from the state of redux store, returned by reducer. Is it right?
I'm quite new to React, and I'm making a single page application with React.
So far, I've build the application with components and child components, having their own local state, however the child components doesn't really interact with one another, which is what I want them to, basically, with the least amount of boiler plate code...
The problem I'm facing, is that a change in some child component, should be able to update the state of another child component, somewhere else in the component tree.
A selection in one child component should also be able to trigger a function in another component updating it with data and so on.
I've considered having just one global application state, that all components can call and update when something in them changes, and this one application state will then update other components in the tree. Kinda like having a single "controller" with it's own state, that all components "views" can call, and which updates the states of other components as needed. (I'm used to WPF and MVC style of GUI programming).
What I've considered:
One could try to implement this with callback functions defined in the top of the hierarchy, to be sent down through the hierarchy and called from a child component when it changes.
This method however results in a LOT of boilerplate code that just passes functions to their child components. It feels wrong and hard to maintain...
To avoid all this passing around and boilerplate code, I've tried using a React Context, however this is not working as well as I hoped. I can only access the context from within the render function and from lifecycle functions, and sadly I often get complicated errors that are hard to understand. It seems like I'm exploiting React Context to do something you shouldn't use it for...
I've considered using a singleton pattern in JavaScript, however then that singleton needs to have a reference to the root component, and query for the component it needs to change... This seems like kind of a hack, and may not be that pretty, but idk.
I'm considering trying out React Redux however it seems to work in many ways similar to React Context (I'll be honest, I haven't read much into it yet).
What I need:
I need to ask someone with greater React experience than me: How do you keep a global application state, and update child components based on changes to the global application state? Also: Am I thinking about this all wrong? Am I trying to do something in a non-react way, failing to see how I should do it in React?
You can happily go with Redux or MobX, they're fine.
I suggest Taming The State from Robin Wieruch: https://roadtoreact.com/course-details?courseId=TAMING_THE_STATE
There are the book and the course. He shows different ways of handling React state.
Redux was created specifically for the problem yo stated.
Reacts follows a top-down down-top unidirectional flow in essence. Context API is useful in simple use cases but would fail horribly in a large scale application where you'd be creating consumers everywhere.
I'd suggest investing some time in Redux so that will save your precious time in long run.
There's a reason all big three frameworks require a state management library to be useful for large scale complex apps. (Angular has NgRx and Vue has Vuex).
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 been using vanilla React for a while, and have now decided to take a closer look at Redux for a new project I am doing.
At first I got the impression that all user activity should result in actions, with one of the main reasons being that you would be able to reconstruct any application state by just playing back the appropriate actions.
The problem with this, however, is that you put a lot of stuff in the store that in reality does not feel like application state. Stuff like "If I focus on this input, the label turns green" does not seem like state fitted for being represented in the application state of an application that is potentially composed by hundreds of components. These things make total sense with the typical todo-tutorial, but it can be difficult to see how it will turn out in a more complex scenario.
Then I read some more, and found that the general opinion, backed by creator Dan Abramov, is that you should usually combine local component state with the application state (store). "Whatever seems least awkward" seemed to be the rule of thumb for where to store state.
On one hand this makes total sense: The things that are really application state, and are relevant for multiple components should be in the store, while the strictly presentational details that only concerns one single component should be handled using normal react state. On the other hand this approach confuses me a bit, because of what I wrote in the beginning: Isn't a big part of the point with redux that you avoid having the state distributed among the components, and that you are able to recreate state by just storing the actions?
I hope someone can shed some light on this concern, because it has been bothering me, and it is something I think I should get a solid opinion about before trying to build something complex with redux.
What state you put where is entirely up to you. Sometimes it may make sense to put everything in Redux, sometimes it may make sense to keep stuff in a component. I recently saw some good rules-of-thumb:
Do other parts of the application care about that data?
Do you need to be able to derive further data from that data?
Is the same data being used to drive multiple components/features?
Is there value to you, to being able to restore the state to a given point in time (ie: time travel / debugging)?
Do you want to cache the data, ie: reload it from state if it's already there instead of requesting it again?
(Credit to https://www.reddit.com/r/reactjs/comments/4w04to/when_using_redux_should_all_asynchronous_actions/d63u4o8 for that list.)
Also see the Redux FAQ on this topic: http://redux.js.org/docs/FAQ.html#organizing-state-only-redux-state .
I've built a web application using React which is up and running and working well. I should probably just leave it alone, but there's one area which is troubling me, where I think I need to do a bit of refactoring because what I'm doing doesn't seem to me to be going with the flow of React. I'd be interested in others' views.
I have a React class, Product, which I use to keep track of products on the page. The only property stored in state is 'quantity', but I have various functions which do things like update a basket by means of pub/sub. Depending on how and where this Product class is used (whether in a table or for a detail view, whether on mobile or desktop), the necessary display is quite different. So in my render function, I call variously 'renderForDetailOnMobile', 'renderForTableOnMobile', 'renderForDetailOnDesktop' and 'renderForTableOnDesktop'.
As I say, this doesn't feel very React-y to me, as if I've got the whole thing upside down (although the rest of the app is, I would say much more idiomatic). So how should be thinking this through in order to break it down into separate smaller classes, which is what I imagine I should be doing? Sorry, for privacy reasons it's not possible to poast actual code, so I hope this description makes the situation clear enough.
You should be using reducers or stores, depending whether you have a flux or redux application. This would help you to understand your state and how it changes.
I see you are using state in your Product, while you should be using stores as mentioned above.
So, how I see the issue is that you have data source and you need to transform it based on the device requirements.
In such case I would make a container which would load other components in charge of transforming and presenting data for different devices.
Container should be rather simple just returning the correct component based on the conditional being met.