View Full Version : About Redux and Ext.data.Store

30 Aug 2017, 1:54 AM

After reading this article (https://www.sencha.com/blog/using-extreact-stores-in-flux-apps/) about using ExtReact with Flux (or Redux), i have how many doubts.

I guess the purpose of have the Ext.data.Store inside Components, instead of out of the redux/flux stores, is avoid that the redux store can be modified by a different trigger than an redux action, for example when you click in the Ext.grid.Panel column header and the sort is configured as remote, pagination or some other stuff like these.

But this give us some other problems, because if we want to have our entire state application in the redux store, we need to rewrite the code to perform remote sorting, groupping and other things that are implemented in Ext, listening the suitable events from the Ext.data.Store like beforesort, groupchange, etc., or from combobox, if it is configured as remoteSort: true, and maybe in each other Ext.Component that represent Ext.data.Store data…

So, I think the second option of the article (to have Ext.data.Store inside Components) have another problems. In my view, the ideal would be have the Ext.data.Store included in the Redux/Flux stores, but overriding Ext.data.Store, implementing some redux middleware or something like this to wrap store (or maybe… the Ext.data.Proxy) to dispatch redux/flux actions.

What are your point of view?

3 Sep 2017, 10:06 AM
The idea is to co-locate stuff that always changes together.

In this case, the store should belong to the component because it's specific to <Grid>. If you swapped <Grid> for <AgGridReact> you wouldn't use Ext.data.Store anymore. (You'd pass an array to setRowData or an ag-grid data source.)

Handle grouping, sorting and filtering events on the grid by updating state in the container/redux and then pass that state as parameters to your remote services.

Once the data comes back, pass it as props to your component and have the store load it using store.loadData.

4 Sep 2017, 12:39 AM
Thanks @j.ashworth. But I would like to have all of these stuffs centralized. My application will have a several number of grids and a very hight level of grid reutilizations. I don't wan't to do this in all redux container logic, and this is the problem we have. Besides, listen sorting and grouping events could be easy, but what about infinite scroll with buffered stores? I think Ext.data.Stores would do their jobs. They do them well, but the problem is the redux status updating. I thought about extend the Ext.data.Store in order to refresh the app state when Ext.data.Store have changes (Ext.data.Store is the real data's owner. Grids are only an Ext.data.Store data visual representation) but I know to link a visual component with a redux Store with the Provider, but I don't know how to do this with an Ext.data.Store, maybe with middlewares... but maybe it isn't possible...

4 Sep 2017, 10:35 AM
What's stopping you from centralizing it?

Write a function/service that accepts grid config and returns a grid (or accepts a grid and returns it). Have the function add listeners to any event on the grid (or its store) that you're interested in and when anything changes, have it write any state associated with those changes to wherever you want (a Redux store if you want, but have a reason (https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjA0NbRlIzWAhUBEJoKHU7EA6EQFggoMAA&url=https%3A%2F%2Fmedium.com%2F%40dan_abramov%2Fyou-might-not-need-redux-be46360cf367&usg=AFQjCNHNSyx82yuY7kTqEwJuedTNWfCidw)), and key it by the something that logically identifies the grid (or store) that's been passed.

Don't forget to unregister the listeners set up by your service if your grid is destroyed.

Edit: Even better, use a plugin. Here's a fiddle to demo (https://fiddle.sencha.com/?extreact#view/editor&fiddle/263j).