Hi everyone ,
There is a use case I would like to implement using AutoGrid: A Hilla app shows a list of items in an AutoGrid in a master view and when clicking on one item the user will be navigated to a detail view. The user will typically sort and filter the list of items in the AutoGrid, because it can be a long list. When navigating back from the detail view to the master view, the user wants to continue browsing the list of items in the AutoGrid, meaning the user wants to continue at the same position in the list having the same sorting and filters applied before the user left the master view.
I’m also aware of the experimentalFilter property of AutoGrid that is mentioned in the docs, but this could only be a part of the solution.
I have some ideas in mind how to extend AutoGrid to support such a use case, but before I go into more detail about these ideas I would like to know if I may have overlooked some existing solutions or workaround to implement the use case mentioned above?
Will you please post your alternative solution? This has been on my radar for quite a long time, asking user to set filter every time is very bad. I am using column filters in combination with external filters.
I had tried to set sorting directions by accessing the underlying web component, and find the component by index, which is very hacky way… and that triggers a grid load call.
I did not try to find column filter and set their values yet.
Thanks for sharing your current solution. With the current possibilities, there is probably no better solution. The fact that no one from Vaadin has yet commented suggests that we have not overlooked anything. Or maybe we did? @Leif@Luciano_Vernaschi@Soroosh_Taefi@sissbruecker
Just my guess: AutoGrid and AutoCrud don’t take priority at the moment because of the new upcoming component that might make those (partly) obsolete - or at least they might be refactored in the near™ future to work with it. Master-Detail Layout · Issue #7173 · vaadin/platform · GitHub
However, one of the fundamental problems that I describe here in the discussion using the AutoGrid component will very probably not be solved by the new component either: The loss of state.
If the master and detail views are organised via a stack or are two independent views that are navigated via a router, then the master view loses its state when you navigate to the detail view. Depending on the implementation, the master view becomes unmounted.
A mechanism is therefore required to maintain the state of the master view. In relation to an AutoGrid component in a master view, this state would consist of the current page or the current scroll index, the current sorting and the currently applied filters.
The AutoGrid component currently holds these states internally. Various approaches exist to maintain these states, for example:
The AutoGrid component could permanently store its internal states using a mechanism such as Local Storage or Cookies.
The AutoGrid component could make the relevant states or properties available externally so that the states could be stored in a higher-level component.
New React features such as Activity could be used to maintain the state of the master view and the AutoGrid component it contains.
We anticipate doing some bigger changes to CRUDs based on two driving factors:
Decomposition. AutoCrud is awesome if your needs align with how it works out-of-the-box. But this approach also means that it has to provide specific APIs for any kind of customization needs. Our design principles are shifting towards providing more flexible building blocks that application developers can combine in their own ways. And then potentially also provide a high-level abstraction that serves as a starting point but that is still thin enough that you can easily just copy into your own project and customize it to use the versatile building blocks in different ways.
Signals. We want to make form binding based on signals. We want to make navigation state based on signals. Both of those will have an impact on how you’d build a crud component.
With these changes being envisioned but not yet scheduled or planned in detail, we try to avoid doing bigger changes to e.g. AutoCrud since we don’t know how much of that would be “wasted” effort that we end up throwing away soon-ish.
With that being said, if you have an idea for some specific small enhancement that could be made to support this kind of use case better right away, then we are still interested in making such improvements.
I am talking about the AutoGrid component, and I would be delighted if we could develop the AutoGrid component further. I am also willing to actively participate in this further development, for example by contributing corresponding pull requests. However, before I start implementing a particular approach, I would like to have some clarification as to which approach is favoured.
I have already mentioned 2 approaches for the further development of the AutoGrid component, but I would like to mention them again:
The AutoGrid component could persist its internal states (e.g. the current page or the current scroll index, the current sorting and the currently applied filters) using a mechanism such as Local Storage or Cookies. The API of the AutoGrid component could be extended with one or more new properties such as keepSorting, keepFilters, keepScrollIndex so that developers can control the behaviour.
The AutoGrid component could make the relevant states or properties available externally so that the states could be controlled (and stored) in a higher-level component. To support this approach, the API of the AutoGrid component needs to be extended with several setter and getter functions like getInternalFilter, setInternalFilter, getSortState, setSortState etc.
The second approach gives developers a lot of flexibility, but requires a deeper understanding of how the AutoGrid component works, which is probably not in the interests of good component or API design.
There are certainly many other approaches. I am open to a design discussion. If the forum is not the right place for it, we could also have this discussion in GitHub.
I don’t think local storage or cookies are appropriate for this case since those are shared within the browser and would thus cause conflicts if the user has the same application open in multiple tabs.
This means that the state should either be stored in global-ish JS variables or in the URL. Which one to prefer would probably depend on the application. This points towards providing APIs that let the application manage the filter and sorting state. Since this is a React component, it might be more natural to define props and change events rather than getter and setter functions.
Good point! I usually don’t work like that. Thanks for bringing that up.
I agree. Looking at the existing AutoGrid API we already have the experimentalFilter prop, which, when set, will be used to set the internal filter of the component. In alignment with this, we could have something like a experimentalSorting prop that does the same for sorting. Having two additional events like onFilterChanged and onSortingChanged would be very helpful, too. Having these props and events in place, would give developers a lot of flexibility to control filtering and sorting, for example to have both represented as URL parameters to allow deep linking.
,