What's the best way to handle a case where multiple components are using one store (which is populated by API calls in an action creator), but each component may need to access different sets of data without effecting the other. I.e.: two table components display data from the WidgetStore; one table wants all widgets, the other only displays widgets whose name contains "foo" (this would be based on user input). The table being queried via the API has tens of thousands of widgets, so loading them all into the store and filtering from the store isn't practical. Is there a Flux architecture (like Redux) that already has a way of handling this type of thing?
The simplest way is to just create a parent component and selectively hand off data, using a pluck or selector function, to each of the children.
For the more general answer for yourself going forward... if you follow something along the lines like redux there is already proven patterns which will help you understand passing complex data down.
Related
i have a page with components distributed by layers as follow:
I have a main page that contains several components and which in turn contains other components. Each level of the parent-child hierarchy I call a layer.
I separate these components into 3 types, reusable, coupled and modal:
Reusable - Receive data by props and do what they need to. They can be reused in any context (page) because they are not coupled.
Coupled - They are bound to the context (page) and can receive data by props or fetch data via API request.
Modal - It is the last layer of the layers, however they are decoupled and receive the data and methods of the actions they need to perform.
The flow I run today is to get the main data when entering the page, then I pass the data via props to the respective components, as the user accesses it.
In some cases, due to the amount or sensitivity of the data, I request more data inside the coupled component, when the client accesses a higher level of detail.
And finally, I pass the data and methods to be executed in the last layer (modal components). There are scenarios where the method is created on the 1st layer (page) and only executed on the last layer (modal).
Based on this context above, what would be the most efficient way to pass data and methods to components?
Currently I pass via props, however, I still have doubts if this would be the best way or using ContextAPI.
I agree with you #kanuos !
After many time thinking about it, I'm using 3 options.
But which one do I choose? As #kanuos sad, depends!!
These are the 3 options I have and use:
Continue using Props Drilling - Some cases is necessary.
Use Context - It works well to avoid a lot of prop drilling.
Composition - Sometimes I want to avoid a lot of prop drilling and I also don't want to maintain a context dependency. In this case using the composition pattern I can directly pass the
properties to what I want.
Let's say component - TodoList need to show the list of TODO's in 2 different ways, listview and gridview .there is a switch on the page that toggles between the views. Assuming I want to keep the 2 views as different components, what is the best practice -
create TodoList component with graphql query and then pass the result of the query to TODOListView and TODOGridView components?
create TodoList component with NO graphql query and then write the same grqphql query inTODOListView and TODOGridView components (not DRY, query duplication in each component, but apollo cache will make sure that it is not called multiple times)?
good/bad with each approach?
IMHO there is no real choice, cache usage has no value as argument then no good parts with second approach.
Taking usability, UX, user centric design you probably want to keep page, sorting and filtering state while switching type of view. As an user you're expecting this kind of behaviour. This is easily available only with first solution.
Assuming I want to keep the 2 views as different components
IMHO this is wrong assumption, too. Of course you can do that but Lists are almost the same, the real difference is in item/row rendering. If this is a simple styling sets change (or adding a few elements) then even no need for using components for items, just conditional rendering. You can change/refactor it later.
Utilizing item components you can have additional abstraction layer and more complex use cases available. With passed down (into items) switching type handler I was able to change it (gloablly) from simgle item level or change locally item view type - mixed element list.
If I have redux store with list of cars.
And I use that list to populate several components like dropdown and for example table (which can be filtered).
When I filter table, my dropdown will be filtered to,
beside it's on other page, they share same store.
And if I clone that part of data in store I would loose option to add/edit on all places.
What are best practices for this kind of cases? And examples maybe?
You should avoid editing the store data from inside the components.
When you filter your list in the component - create a new, cloned instance of the list - to be sure you don't change anything in the store.
When you want to change anything in the store - use actions.
You should keep the Store data as readonly in Components.
I found a good article on this topic https://hackernoon.com/redux-step-by-step-a-simple-and-robust-workflow-for-real-life-apps-1fdf7df46092
As I can see this article explains this question well, didn't see it earlier:
http://redux.js.org/docs/recipes/ComputingDerivedData.html
So this could be correct way to filter or do anything else without polluting the store data.
This is not a React specific question. I'm thinking of implementing Flux in Aurelia/Angularjs.
While reading up on flux, I'm not convinced of the need of the dispatcher step. Why can't a component call the store directly to update and retrieve data? Is there anything wrong with that approach?
For example: If I have a CarStore that can create new cars, update cars and get a list of cars(just a thin layer on the CRUD api), I should be able to retrieve/update the list by directly calling the store from the car-grid component. Since the store is a singleton, whenever the list updates, car-grid should automatically get the new items. What is the benefit of using a dispatcher in this scenario?
I've created several large apps using React-native with Redux as the store / view state updater.
The dispatch action is synchronous regardless. There's a big disadvantage to using dispatchers, you lose the function signature. (Debugging, auto-catching type-errors, refactoring lost, multiple declarations of the same function, list goes on)
Never had to use a dispatcher and its caused no issues. Within the actions we simply call getState().dispatch. The store is a singleton anyhow, it's heavily recommended you don't have multiple stores. (Why would you do that...)
You can see here why are dispatchers important (check out the section Why We Need a Dispatcher). The way I see it, the idea is basically being able to access to various stores in a synchronous way (one callback finishes before another one is called). You can make this thanks to the waitFor method, which allows you to wait for a store to finish processing an action (or more tan one). There is a good example in the docs. For example, your application may grow and instead of having just that CarStore you have another Store whose updates depend on the CarStore updates.
If you will only ever have one store, then a dispatcher is redundant in my opinion. If you have multiple stores however, then a dispatcher is important so that actions don't need to know about each of these stores.
Please note that I am not saying that you should ditch the dispatcher if you only have one store. It's still a good pattern as it gives you the option of supporting multiple stores if you ever need to in the future.
I'm working on a project which has only been going a very short time. There are few flux stores in place already which manage different aspects of the application state and are relatively independent.
I have 2 questions :
Some of the stores that exist are emitting more than one type of change event. Is this indicative of the stores handling too much unrelated data that should be in separate stores or is this a usual situation?
We need to write a React component that is dependent on more than one of the stores that already exist, and also needs to query the server to get some specific information to render on the page which it will then allow the user to modify. So, before this component can render, it needs to ensure all the stores contain what they need to and issue actions to populate anything that is missing. My question is about how to handle this. Would it be better to create a new store that fetches the specific data required by the component and is dependent on the other stores (using the usual flux store dependency rules), or to have the component knowing which specific stores it is dependent on directly.
For first part of your question: it depends. Flux doesn't force you to follow strict set of rules. Redux for example, uses only one store for everything. I worked on project where almost all components had there own store and another one where we had single store per view that handled data model and all additional states. Without knowing specifics of your project (size, complexity etc.) I can't recommend one over the other. I would probably go with minimum number of stores that make sense to you and your team and refactor as needed (ie. when you feel it handles too much or single file contains too much of unrelated code). Whatever works best for your situation and makes you most comfortable.
For other part: since you want component to render only after data for all stores is populated I would introduce new store to handle server data and use Dispatcher’s waitFor method to define dependencies. If you opt to use stores directly you could then render component using some kind of intial state with loading spinner over parts that are missing or disable user editing and, once data is fetched, update state to display rest of the data/enable editing. This requires more code but can result with better UX. Again, it all depends on your needs.