Serialize/deserialize filters

[kum-deepak]

These capabilities can allow a few interesting use cases:

• The serialized filters state can be sent to the back-end which can update data for all charts and send in a single request. For this to work more changes will be needed which will be taken as independent PRs.
• A user will be able to save their favorite state(s), which can be saved in the backend and restored later.
• An undo/redo functionality can be implemented (a mechanism to watch filter changes will make it easier).
• The dashboard creator can provide a canned set of filtered states.

Currently, these are not covered by test cases. I have modified the stocks sample to add options to save and restore.

Give it a spin when you have time.

[kum-deepak]

Before the final release of this library, I have the following additional targets:

• Create an example that shows undo/redo capability for filters. This may need some additional work to do it properly. I am targeting to do that as part of this PR.
• Create a widget that shows current filters - with possibly an :x: button against each allowing clearing individually.
• I will investigate at a later date if this will allow the ability to easily add/remove filters outside the chart (without extending the chart itself), by creating a chart that shares the same dimension. cbox-menu can be a good starting point.
• An example to use these capabilities for remote data (more capabilities needed first).

There is also a peculiar issue with the current .filter call in the charts - it returns only the first item if there is more than one filter. This may confuse users - it is not necessary to tackle for this release though.

[gordonwoodhull]

Great plan, thanks for explaining.

Yes, .filter() returning one filter is sort of consistent because .filter() also takes one filter and toggles it, and there is .filters() too.

But it’s a weird interface for sure. Don’t forget how .filter() can take an array where the first element is an array of filters, and each one is toggled!

My guess is that the need for more than one filter was not originally anticipated. But I haven’t looked back that far.

I tend to think it would be too confusing to keep the same method name and change the meaning, since there are so many examples out there. But I’m not dogmatic about it. The new version, with or without a new library name, is going to be a big change.

[kum-deepak]

I agree with .filter being used widely. I am not keeping it a priority, because it works and does not hamper any feature anywhere.

[kum-deepak]

Merged commits other than the sample. I will be working on samples as separate PR(s).