Repository navigation
Expose state object/plugin methods or common plugin object in all context instances #697
Description
Activity
I'm against exposing the state, because after that changes to it would be breaking. Also it encourages people to start tinkering with the state, which would be horrible.
That said, I haven't taken the time to think about that use case and what kind of API would bee needed. So lets keep this open and find a better solution.
I'm against exposing the state, because after that changes to it would be breaking. Also it encourages people to start tinkering with the state, which would be horrible.
I agree and for this reason I thought that an object (shared across all contexts) could be a good compromise.
Related to this topic, I spent time last weeks to have a look to other js chart libraries and how they are addressing the annotations topic. I think this plugin have got almost everything is needed. The only thing that in same libs I have seen is an annotation where the user can draw own path. we have already touched this topic. This is just FYI. Allow customization is always a pain point because is forcing to review many other items to maintain the consistency of the plugin.
- locked and limited conversation to collaborators
on May 24, 2022
Use case
Preparing the inner chart sample, I have seen a possible difficulty to manage the change of the cursor when the mouse if hovering the annotation elements.
Current status
Currently, the events are triggering the callbacks with only 1 element, the nearest one. With PR #659 you could have more than 1 elements and this could affect the change of the cursor because before changing the cursor you should must be sure that there isn't any affected elements from hovering.
Possible solution
The user should know if there is any other element.
Of course the user can develop the counter management and store it in own object, shared in the application, but it could be helpful:
state.hovered)Probably there are other use cases.