Add support for advancedFilterModel as callback output

[ctdunc]

Hello -- I am working on an app that leverages the advancedFilterModel in ag-grid. I have some serverside logic which cannot be moved to the client which is used to set the default filter state. I would like to be able to set the filter state using this logic after the user has changed it, which cannot be done using the regular filterModel output.

Ideally -- this would work by having an advancedFilterModel callback output that calls setAdvancedFilterModel with the output, roughly how the filterModel output currently works

[BSd3v]

Hello @ctdunc,

How you looked on the forums, I believe there is an example of how you would be able to perform these actions.

[ctdunc]

this might cover my use case, if it is what you're referring to (for future readers as well :) ). I'll give it a shot.

Regardless, it's still less ergonomic/readable than having direct support for the field as an output, so might be worth considering adding support anyways.

Thanks!

[BSd3v]

AG Grid has a lot of things that would be worth considering, however, it was the initial design to limit the number of properties that come over due to how prop suggestions work.

The original wrapper had all the props and was very messy. We limit the props and instead give you the power to be able to manipulate the grid directly through apis, dashGridOptions (to catch anything not explicility defined as a prop) and allowing to add eventlisteners.

With the addition of dash_clientside.set_props in dash 2.16+, you can directly impact a component without needing to perform a callback. However, since you are using it for serverside, you can use the dash_clientside.set_props to trigger a callback by manipulating for example a dcc.Store.

---

This was the post I was referencing:

https://community.plotly.com/t/capture-and-save-filter-expression-from-advanced-filters-in-python-dash-ag-grid/84838/2?u=jinnyzor

[ctdunc]

Thanks for the link!

I see now that it's possible, but I'm still struggling to see how this solution is cleaner than just providing access to props. I'm not sure what you mean by "how prop suggestions work." Do you mean LSP/IntelliSense suggestions? Because this would just be adding a string to a Literal, no? Or is the challenge surrounding implementing user requests for prop support?

If you have the time, could you link to any publicly available discussion/docs surrounding the decision to restrict access to these props? I'd be interested to get some more context.

Regardless, I still think this prop is worth supporting, as it makes 2 API calls ((g/s)etadvancedFilterModel), and prevents the need for workarounds with dcc.Store. The extra layer adds unneeded complexity, and is basically boilerplate, since you're just doing a callback with the extra step of calling set_props. This pattern could easily become confusing/borderline unmaintainable with pattern matching callbacks and multi-page apps, since you now need twice the number of callbacks to achieve the same result, setting both the store and calling set_props.

I'm sure there's some wizardry with pattern-matching that can be used to reduce the number of callbacks used here, but in a large project, it may ultimately harm readability, which is a significant issue, as we generally prefer to keep page logic coupled to the page.

[BSd3v]

The discussion was an internal one. The component currently has 48 props, including the dashGridOptions, which is the catch all for sending properties to the grid.

Depending upon your IDE of choice, with the more props that get added, the longer these options will take to populate:

In the original AG Grid wrapper, before open sourcing, there were well more than the 48 we have here. When interacting through an IDE, it took a good amount of time to have interaction back after it trying to make suggestions. Not only is this a concern, but the more props that we add, the more props will need to be maintained. This was what led to the decisions about the props.

The prop you are mentioning would be the first standalone prop for the Enterprise Grid, based upon an event setting up a prop, which by itself has a lot more props to maintain.

If you are looking for readability and DRY mentality, I'd recommend creating an AIO component where you can add this functionality and allow for being able to re-use the component throughout your application.