I have an event component and a container class that lists the events. I am struggling with deciding between these two options
Have the container class get the list of event_id, pass the event_id to each event component, and have each event component fetch its own data.
Have the container class get the list of events objects, and pass the event object in as a prop to the event component.
The user can edit events, so the event components needs to be able to handle updates.
With option 1, I will only need to make one fetch to the rest api, but then the container class has to manage the state of each event in case of edits.
With option 2, I will have to make a fetch request for each event, but then each event object can manage its own state.
Which option (or any suggested 3rd options) should I implement?
I'm with the first choice ...
It's better always to reduce your requests.
And in react it's better to make your design such as .. less containers .. more components
I mean that if you can manage all your components in one container this would be a better solution
Another Case .. Maybe you'd have to transfer state or to make interactive between event components .. this would be much harder if you make every component fetch data by itself
So I'm with the first choose
Update:
Will it be displayed with the same event handler ? If yes .. than the other choice will be better
what I mean that: some time you have component with event handler .. but this event will be handled differently in each parent component(like when you have custom button components with some styles .. but one-click event will be handled differently depending on parent component) .. so the first choice will be better
but if it's handling same event in the same way each time then the second choice will be better
Both the approaches are correct, and nothing wrong to go over another.
It all depends on how your UI wants to show these events. If data from multiple components (event component and a container class in this case) needs to be in sync, then move state data to closest parent component of the components that need it and handle updates through callback functions. If not, move individual event operation in child(event component in this case) component
Related
What is the best practice to implement a multi step form?
I know that there are several different practices, but which one is the best/most performant ?
Redux/Global state management: Easiest but bad for performance, because it will check every connected component on every key hit.
Raised State: Have a parent component keeping all state, but this couples the components too close together and makes the parent component too complex
Render props: The child components render the next button of the form as a render prop and push their data to the parent on next click => this makes the parent complex as well and it may be difficult to pass the data to the parent.
What are your thoughts? Thanks in advance!!
I would go for the second option, because it keeps the children simple and dumb (MVC).
The parent component keeps track of all data and which form is currently displayed, which keeps all logic within one component (which makes it easy to update).
Performance won't be a problem, because it only displays one form anyway, so the performance is the same as if using a single form.
We've been using redux-form and seeing a noticeable lag when user types in an input field. I'm not really sure if it's a problem with redux-form. This could probably be the way we've structured our components. So we have page which lists some data, say 25 rows and filters for it. On click of a button, we open a modal where we render a redux-form. Now if user types in any of the input field, all the list items in the underlying page also get re-rendered. We're using React.Component for list items. React devtool's "Highlight updates" option highlights list items but when I do a console.log in list item's render method, it's not printing!
Wonder if this is happening because the list item's parent component is also a (redux) connected component and when redux-form's Field updates the store, this also gets re-rendered? How do you use redux-form in such scenario? I don't think having multiple stores is a recommended way.
I'm guessing you have an event listener for when any of the inputs on the form changes, and then you do some fetching/filtering on the underlying list?
Running this when typing quickly could lead to a performance hit, depending on what your event listener does. You could try using something like lodash.debounce to only run your listener after the user has stopped typing for like 200ms?
Let's say we want to create a new Task. We have 2 categories of information we want to collect from the user for creating a new Task: general params, action params.
To make it easily separated we are separating between them with tabs. so each gets its own react component, both stored in different react-tabs tabs.
In the parent component I have a save button and I want that at any given time, the user could click it to send the entire state from both the tabs' state to the server.
While I could forward event handlers from the parent to the children (as suggested by other questions on this topic)... doing it for each of the 20 controls (dropdowns, textfields, date time pickers) in each of them requires a lot of boilerplate code and seems unreasonable.
I'm looking for a best practice for this situation. Thanks!
How should Modal window be shown while using the Flux implementation. I can have the Component update its state to display a modal and close it once done. A save in the modal would trigger a action and update the store. But the modal would not that it needs to be closed. I would then need to emit a different event or have the store store the state of the modal.
For me it is perfectly fine to store the state of the modal in the store. On save event, just use a boolean value to say whether or not the modal should be displayed.
Your store doesn't need to have a single attribute, it can be more complex. Like having an array and a boolean.
When the save happens, just update your array and put a boolean open=false that you will use in your render method to not render the modal anymore. You don't need 2 actions to do that, one action can update your store model + update the boolean to false.
The complexity here is to know what to put in stores. How to organise your state... This can become quite complex over time. Until now I have found great success by using autonomous components, with their own stores, like widgets. You can find more details here.
In a more general way, you can put layout properties in stores. Like cursor or mouse position, opened modals, whether mouse is over some element or not...
Quick question about good form in a React.js app:
I have a top-level App that has a state like "selectedItem", and want a ListItem component to be able to change that state.
So you make a top-level method on App like selectItem: function(item) that does a setState(selectedItem: item).
App passes this function down as a property to List component.
List component passes this function down as a property to ListItem component.
Finally ListItem component uses it as the onClick handler, with a .bind(null, item) so that the top-level state can be changed by a clicked item in the list.
Is this right?
It seems quite messy. Seems it'd be nicer for the ListItem to be able to call App.selectItem(item) directly without it having to be passed down three times.
If ListItem is directly aware of App and its selectItem method, then ListItem is coupled to that application—it can never be reused in any other context. For components to be reusable, they should generally take a change (or whatever) handler as a property that it will call when appropriate.
As for components that are specific to your application (that is, they're not meant to be reusable), all that passing around can get messy. There's an architecture called flux that allows application-specific views (known as "controller-views") to interact with an application-wide dispatcher in much the way that you mention.
In short, reusable components should be passed props to make them maximally portable; application-specific components can access application-level logic directly, though many people still recommend passing properties as it makes data flow clear and explicit.