Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose state object/plugin methods or common plugin object in all context instances #697

Closed
stockiNail opened this issue Feb 24, 2022 · 2 comments

Comments

@stockiNail
Copy link
Collaborator

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:

  1. have the access to the state to have the count of affected elements (state.hovered)
  2. or expose some methods at plugin level to get this (and other info)
  3. or have a common object instance where in all context where the user can store the counter

Probably there are other use cases.

@kurkle
Copy link
Member

kurkle commented Mar 4, 2022

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.

@stockiNail
Copy link
Collaborator Author

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.

@chartjs chartjs locked and limited conversation to collaborators May 24, 2022
@stockiNail stockiNail converted this issue into discussion #750 May 24, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants