So I have heard it's good to keep them all in one folder in your src folder but then if I ever wanted to use the action from somewhere deep in my component tree, I'd have to:
import increment from '../../../../../actions/increment';
Alternatively each action could be kept in the folder I'm using it in, but then if two different components needed to use the action, I'd have to send the action through props or make a copy of it.
I'm sorry I'm a complete newbie with Redux. Is there a nice concise way to do this?
If you follow current standards, you don't even write action types or action creators. Please read Why Redux Toolkit is How To Use Redux Today.
As for the question as hand, file organization is handled in the Redux Style Guide
Related
I just recently got introduced to Redux and decided to learn how to implement it. At the moment I'm refactoring some of my previous studying-projects and implementing the global state logic provided by the tool.
The thing is, I've recently stumbled upon the thunk middleware for async actions and got curious about something that's probably a simple concept misunderstanding but that I just can't get over.
So, why would I dispatch an async action? I just can't see the benefits of doing that way instead of waiting for the execution of whatever I'm doing and just then dispatch the action carrying the data I want.
Using a simple fetch call as an example, why would I not do the following:
->await fetch data
->dispatch fetched data
And instead do this:
->dispatch action
->await dispatch action
There's probably some use cases that I don't know of because for me, a beginner, sounds like extra code for something that maybe didn't require it? Idk.
Could someone help me? =)
Yep, as you found, that's Dan Abramov's original explanation of why something like the thunk middleware exists.
I recently wrote a new Redux docs page on Writing Logic with Thunks, which goes into more detail on the purpose behind thunks and how to use them correctly. I'll quote from the "Why Use Thunks?" section:
Thunks allow us to write additional Redux-related logic separate from a UI layer. This logic can include side effects, such as async requests or generating random values, as well as logic that requires dispatching multiple actions or access to the Redux store state.
Redux reducers must not contain side effects, but real applications require logic that has side effects. Some of that may live inside components, but some may need to live outside the UI layer. Thunks (and other Redux middleware) give us a place to put those side effects.
It's common to have logic directly in components, such as making an async request in a click handler or a useEffect hook and then processing the results. However, it's often necessary to move as much of that logic as possible outside the UI layer. This may be done to improve testability of the logic, to keep the UI layer as thin and "presentational" as possible, or to improve code reuse and sharing.
In a sense, a thunk is a loophole where you can write any code that needs to interact with the Redux store, ahead of time, without needing to know which Redux store will be used. This keeps the logic from being bound to any specific Redux store instance and keeps it reusable.
The Redux FAQ entry on "why do we use middleware for side effects?" links to additional information on this topic.
Hello everyone Im doing a search bar using react and got a program, before I was passing data between components parent > child, child > parent but now I need to pass from my src>components>toolbar>search bar to src>containers>category component, someone could help me?? thankss
Another way to achieve this, by creating and dispatching an event and listing this in a component.
componentDidMount() {
this.nv.addEventListener("custom-event", this.handleNvEnter);
}
componentWillUnmount() {
this.nv.removeEventListener("custom-event", this.handleNvEnter);
}
handleNvEnter = (event) => {
console.log("custom-event:", event);
}
I looked at your question and the first thought that came to my mind was introducing Redux.
You can do this by installing a few packages using npm.
Redux (core library for Redux) Redux documentation
React-Redux (Redux is a apart from React and needs this package to work cohesively) React usage with Redux
Honestly I could ramble on and tell you how to integrate every little detail. But I'm not going to do that instead I'll give you an overview of how you would use this technology to your benefit. Be warned this is going to require a bit of time to master, however in doing this your ability to design complex systems will be greatly enhanced.
Firstly, you're going to want to learn a bit more about how Redux stores and data. Here is an introductory course by Dan Abramov the creator of Redux Redux course. It isn't too long and is free!
Once you're familiar with stores, reducers, action creators, actions and the Provider component --->Close your laptop<--- and take out a pen and paper and map the hell out of what belongs where. For instance, your search data belongs in a reducer that handles it, and your going to have to design your actions accordingly too plus read their payloads and map them to the store.
Now code it. With the design being completed and necessary information on how to develop with redux, this should be a stroll in the park.
Hope this helps your question.
I think the best way to solve that problem is to use Redux (https://redux.js.org/basics/usagewithreact) which is typically used for storing the values and which you can use it throughout the application files.
The below links will help you understand Redux and how to implement to your react application:
https://github.com/bradtraversy/redux_crash_course
https://www.youtube.com/watch?v=93p3LxR9xfM&t=537s
https://github.com/bradeac/using-redux-with-react/tree/master/src
You can pass the data up to the topmost parent and then pass it down again to the child you want to.
Say I want to create a little editor for my software that helps me organise people in my company. I will use React & Redux. The editor is a React component (or maybe container?), and it shows me one person at a time. I can edit things about this person, delete fields, etc. and when I am ready I can click a button which will then give me the next person to edit.
Now, I am quite new to React still and can imagine doing this in 2 ways:
Solution 1: Decouple the editor component
Create an Editor Component, which takes an array of all the people in my company. I do have these people saved in the Redux state of my app, but the editor component will not work on my Redux state, but do all changes in its internal state first, and only once I click save will the Editor component commit these changes to my Redux state. This might be a problem, and changes could get lost if somebody doesn't save their edits.
The advantage here is that I have my Editor de-coupled from the rest of my App, and the logic of the Editor will stay in that component.
Solution 2: Connect the Editor Component to Redux
Here, I would connect my Editor component to Redux. So I would not give my component the people array, but direct access to the my Redux store via selectors (for example). I would also not have a deletePerson() function internal to my component, but pass this down as a prop into my component (and it would presumably be a Redux action). This way my component would work directly on state, which I can see as having advantages.
But taking it out of this app and reusing it somewhere else would get more and more difficult, the more complex my component becomes.
Please remember that I am a beginner and that these two solutions are what I came up with as a response to a problem I am facing in my own application. However, I would appreciate if you could help me out here, and explain to me how I should think about problems like this. Is there maybe a third solution I am not mentioning? Or am I misunderstanding a concept?
Personally, I am inclined to go with Solution No. 1, but I also know that the whole idea of Redux is to keep state in one place. What would you advise? Are there performance differences / advantages with one solution?
Your first solution is good but why not use a service when its provided?
You should try to mix up features of Redux React. First, separate your presentational and container components and in one of your container component pass the props directly to redux store on click,etc. Then use redux actions to access the store like deleting,etc. Provide a UI using React presentational components for data entry and pass this data to redux store. Use redux actions when you think they will be useful and not destructure your app.
Go to https://medium.com/#dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 for further details on how to connect presentational and container components.
I don't like the file structure of:
...
reducers/
actions/
components/
...
I would much rather store the items in a more logical and easy to edit format, i.e.
form
- box
-- radiobox
-- checkbox
- text
-- text
-- textarea
This is just easier for me to add components and maintain meaning for each file and it's appropriate tracking. Adding Redux complicates this as such, but allows the same structure.
Example files would be RadioBox.js, RadioBox_Reducer.js, RadioBox_Actions.js
How can I do this using some tricky import or method of importing. Of course I want to automate it all so I'm not importing these myself (if possible).
As I'm new to React and Redux, I am also open to suggestions as to why this behaviour is really bad, like really bad.
Frankly it doesn't make sense to add whole bunch of reducers and actions for simple things like radio-box, checkboxes. You can use local component state for that. Ask yourself if you want to use the checkbox property in multiple components or you want to serialize the state for persistence ? If the answer is no, you do not need redux here.
The way I use redux is to store data like users, products, collections, orders etc. which you fetch from api. Also rarely reducers are named after my components or screens but rather logical data in the app. read this for more info.
Also you can use duck-pattern to avoid that folder structure.
I was wondering if there's something wrong with the approach I'm trying in this link:
https://t.co/WSV81eDwkr
Basically the idea is to modify only the actions file when you add a new action.
on of the Improvement I'm thinking is to recursivle merge the status passed from the actions with the reducer's state.
Let me know
Good thinking. Unfortunately this is an anti-pattern in redux. Actions are supposed to be "pure", stateless, and non-mutating. You are accessing the state directly from an action, which is circumventing the flow of data (oldState => view => action => reducer => newState). Of course the framework is there to help you so if you find that this solution scales well with your project, it could be the way to go.
But to answer your question, it's definitely the wrong approach if you are trying to keep the Redux approach. Another issue I see is that you can't easily serialize actions so it'll likely break time traveling and the redux dev tools if you were to use them.
It's true that there's quite a bit of boilerplate involved in Redux but it's the price to pay to overcome all those CONS you listed with this new approach. Debugging the state of your application is much harder in this scenario.