Feature: Pass plugin values to Tippy props

[baleeds]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[X] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

In Tippy, if you add a plugin, that plugin now accepts a value on the TippyProps matching that plugin name. Helipopper does allow adding plugins, but there doesn't appear to be a way to pass those plugin values into the TippyProps from the TippyDirective.

This means that the plugin strategy for Tippy is handicapped in a way that is preventing me from solving a problem.

Expected behavior

Ideally, there would be an input like [tpPluginValues]="{ myPlugin: 123 }" that would pass these values into the TippyProps. I do understand that there could be some annoyances if somebody names their plugin the same thing as a "core" tippy prop, but this is how the Tippy plugins work.

What is the motivation / use case for changing the behavior?

I'm trying to write a plugin for a "singletonGroup" which allows only one Tippy to be open per group key. I can't pass the group key into the plugin though. Plugins are useful for the maintainer of helipopper because people can extend the library with bespoke functionality.

Environment

Angular version: 17


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version:   
- Platform:  

Others:

[NetanelBasal]

You're welcome to create a PR. We can use inputs or DI to pass it.

[baleeds]

I'm clear on how to use inputs to pass it in. Not sure how DI would work, could you explain a bit more before I get started?

Something like this?
https://github.com/ngneat/helipopper/blob/master/projects/ngneat/helipopper/src/lib/tippy.directive.ts#L99C5-L99C63

[NetanelBasal]

The real question is whether you expect the plugin to apply globally to all instances or just a specific one?

[baleeds]

Well, you can provide a default value for the plugin which would then apply globally. What I'm trying to do is create a plugin that exists for all instances, but only takes effect for instances that have a specific prop value.

Sort of like this code from the Tippy docs:

import tippy, {followCursor} from 'tippy.js';

tippy(targets, {
  followCursor: true,
  plugins: [followCursor],
});

In this scenario, you can provide the followCursor plugin but set followCursor to false and it wouldn't apply to this instance.

[NetanelBasal]

So we could add the plugins at the config label and expose additional input that will apply it as in your example.

[baleeds]

So we could add the plugins at the config label and expose additional input that will apply it as in your example.

Correct, that would be my aim.

The plugin values exist at the top level of the TippyProps. The structure of a TippyInstance looks like this:

{
    "id": 21,
    "popperInstance": ...,
    "state": ...,
    "props": {
    	"appendTo": body,
    	"delay": 300,
    	"followCursor": true,
    	...
    },
    ...
}

That means that the functionality in the TippyDirective is going to be spreading these "plugin" values into the tippy props directly. The question then becomes, should this @Input() be named something specific to plugins, or generic to tippy props?

Here's what the usage could look like:

<app-my-thing [tp]="tippyTemplate" [tpPluginValues]="{ followCursor: true }">

or

<app-my-thing [tp]="tippyTemplate" [tpTippyProps]="{ followCursor: true }">

[NetanelBasal]

tpTippyProps If it goes to tippy props