Allow multiple triggers to modify a single toggle-able node

[aaronstezycki]

Is your feature request related to a problem? Please describe. Allowing multiple triggers to interact with the same toggle-able element would be very welcome. For example, a main navigation trigger/button might toggle a modal or 'sidebar' into view. Being able to click on a body link/button trigger to open the same 'sidebar' would allow users the flexibility of which trigger to use to access the modal.

Describe the solution you'd like Something like ...

<header>
    <button data-toggle-class data-toggle-target=".modal">Open Modal</button>
</header>

<main>
<p><button data-toggle-class data-toggle-target=".modal">This also triggers</button> the modal, but if the modal is already active, it would close the modal instead.</p>
</main>

<!-- is-active from any trigger that targets it -->
<nav class="modal"></nav>

Note: This would also need to work with radio group based triggers. (This is the specific use case I need)

I don't have the time to put together a reduced test case at the minute, but would like to when I have time. This is a great library, and I'd love to see it improve further to solve more edge cases.

[Twikito]

Hi @aaronstezycki 👋 Once again, thanks for taking time to send this request.

I see your problem, here. Since the behaviour is to toggle classes, if you have two different triggers that target the same element, toggling the same classname, you'll have a conflict. I would probably think about a way to link triggers.

In your example, I tried to fix the problem, and it seems you can have a acceptable behaviour by adding data-toggle-outside on each trigger. What do you think?

[aaronstezycki]

With both triggers, or any trigger for that matter, you could have a query function which checks whether the target has the class on it already... then if it has the class already remove the class (or classes) or if it doesn't have the class, add the class on to target. I'm willing to bet this would solve a few different problems that the library might suffer from?

I'll check to see if your solution works in the meantime, altho maybe creating a different data attribute name to solve this use case might be preferable.

[Twikito]

Well, I have already think about such a behaviour, but it can't work since the developer can add whatever classes he wants by default, so on toggling, a trigger or a target can have some and don't have others. The behaviour is to toggle, and not arbitrary choice what to do with the classes that can be already set.

So I think that yes, I may add a new attribute to create a link between triggers.

[henrijs]

I agree @Twikito, an attribute would be in order, since there is more going on besides classes, we need to swap ARIA attributes as well properly. My use-case are tabs that become accordion on narrow screens. But I have options, like https://css-tricks.com/transformer-tabs/

[aaronstezycki]

In your example, I tried to fix the problem, and it seems you can have an acceptable behaviour by adding data-toggle-outside on each trigger. What do you think?

I've just tried this approach and un-fortunately it has some unwanted side effects. :( Obviously just clicking anywhere on the document might close or toggle the target, which isn't really what we want.