Feature request: Add ability to track the source that triggered refinement

[flevi29]

While developing my own custom Angular components using the exposed connectors, I found that a lot of times when a widget triggers a change, its component should not react to its changes, or react differently when the source of change is the widget used in the component. Point is there can be made optimizations when we know the source of the change.

Examples

• While implementing instantsearch.js interface Router to use @angular/router I noticed within createRouterMiddleware.ts when router.onUpdate triggers, this will also trigger onStateChange, which in turn triggers router.write if lastRouteState differs from routeState. But in this instance it should never even get to comparing these two, because it's nonsensical in this case to react to it's own changes. (on a side note I believe comparing these route states should be the responsibility of the Router, if it will do it at all, it's up to the implementation) So in turn there needs to be special logic and caching in Router in order to determine when to trigger a route write and when to trigger a IS.JS state change. If router.write would receive the source of the change, we could determine that the change was triggered from within the Router and simply ignore it.
• The SearchBoxWidget has no way of telling the change came from itself, so there's always a needless comparison between the content of the input element and state query, in fact it can only be changed by the Router if I'm not mistaken
• Correct me if I'm wrong, but SortByWidget currentRefinement can only be changed by the Router or refine in the widget, potential optimizations pop up
• The list goes on...

I'm not sure if this is true, but all state changes trigger all callbacks, there's no selectivity, this ideally should be handled internally, but a more simple solution for now can be my proposal. Which is the ability to pass a variable of any type to the refines, and to receive this optional variable on state changes everywhere else as the identifier of the source of the change.

So for instance if on the SearchBoxWidget we refine with a Symbol object as the identifier, on the callback we can check against this Symbol to determine that the change is from within or from a specific widget.

EDIT: I can see that there is a property on the widgets: $$widgetType. If this would get exposed somehow as the source of the change it would pretty much be exactly what I am looking for, albeit maybe a little less flexible and more limited.

[Haroenv]

Unfortunately there's also changes possible from for example setUiState, results, so any optimisations would need to have to take that in account as well. You can also have multiple of the same widget, which would also impact all other widgets.

Are you seeing actual performance impact from these comparisons in the life cycle that you'd like to see optimised or is this more hypothetical?

[flevi29]

It's hypothetical, I'm pretty sure it won't help with major performance gains. Where it could really hurt the performance is unnecessary re-paints. But these can be side stepped in the component implementation. For example in the SearchBoxWidget we can always check against the contents of the input element.
I'm coming more from a DX -ish angle, I guess it just feels like I am forced to utilize broad solutions, whereas there could be exact solutions. It hurts my OCD a bit.