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...
Related
I want to build a simple app like in picture attached with react js, I just cannot find the right idea of:
How to "select" photos(or item) in an application and have the "cart"-like component appear at the bottom when at least one photo/item is selected(and close and deselect all already selected photo/items) and expand the cart-like component at the bottom when clicked to show what's been already selected.
What is the best approach to this?
P.S I'm new to react with a big idea in mind xD
app's view
This question definitely needs more information, but I will try to point you in the right direction. There are hundred of ways to create the UI/functionality you are describing but here is a very generic overview;
The "items" (Img1-6) looks like a grid of ShopItem components, possibly in a CSS Grid / flexbox. Each ShopItem would probably make use of an onClick method to "do something" when it is clicked - this may involve updating a state (using the useState react hook) somewhere which tells you if a ShopItem is checked or not. It could also potentially use a callback method to do something in the parent when the items are checked.
I imagine that each ShopItem may own its own "checked" state or may update a global state (Such as Zustand or Redux) or a Context (React) when it is toggled on and off. The checked state of a ShopItem would also inform the UI of the component.
The "cart-like" component could be looking at the global state/context/callback from the item component, and could change based on its value and how many checked items there are. (Eg/ checkedItems !== 0 ? show : don't show)
This is just one way in which this UI can be built, if you would like a more specific solution, please edit your question to include code snippets and what you've already tried.
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
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?
I have trouble coming up or finding the boundaries of the so called "UI State".
Imagine the example of an issue tracker:
We have a list of "issue cards", which each contain:
A simple icon that represents the progress (i.e. open, closed)
The description text of the issue (a simple <p/> element)
A single Action button that changes d =epending on the state of the issue: "Assign to myself" or "Mark as done".
A button that opens a context menu (AKA right-click menu). This menu has a list of a variety of action buttons. Depending on the
state, some actions are greyed out and can not be clicked / or are
just not shown. Like "Close Case", if the case is already closed.
If you could categorize each of these items into UI-State vs. Application State, it would help me understand the boundaries.
More practically: How would you divide this little example application into containers and presentational components?
My interpretation: 1. and 2. are just presentational, 3. and 4. are stateful. Is this right? How would I structure this as containers and components?
Thank you very much!
All of listed examples are examples of application state, where UI is determined by persistent data that is received from the backend.
UI state usually refers to UI component local state that is determined by user actions, e.g. window position, active tab, unsubmitted form values, etc. Depending on the case, UI state may be lifted up and stored somewhere (persistent storage or URL) or be discarded.
if I want to implement this project I would act like this :
a component for managing all children components
a store to managing model, data and fields
a component for displaying icon and description text and button
a component for context menu
please consider that if you are using MVVM pattern, be sure that all responsibilities of actions are done by store and for changing some properties use observable fields
and if not use state in manager component and pass via proprs in children.
My page is composed of hierarchy of classes and many reusable components. Multiple instances of a button component can exist anywhere in the page and on click they fire actions that populate different types of data in a common sidebar list component.
The requirement is to highlight the button that was last clicked to load the data in that sidebar list. Of course, it also means to remove highlighting from the previous button. Since these button can exist in different components, I cannot manage state in one parent component.
I am not able to find a solution in pure React. I don't want to use jQuery rather just stick to React. Note I do use Redux in the app though and would be fine with leveraging Redux state if required.
You should most definitely use Redux. You'll need to create a variable in Redux that gets updated whenever an action takes place that would require you to highlight the button on the page. Then use conditional styling for the button based on that variable.