Warnings for targets not inside controllers

[DawidJanczak]

Hello,

We have some complex partials reused between different controllers and we end up with markup like this:

<div
  ...
  data-foo-my-target='input'
  data-bar-my-target='input'
>

The thing is when we render the partial containing this we will only ever have one of these controllers. So another partial containing FooController will render this once and yet another partial containing BarController will render this elsewhere.

This leads to The Stimulus target '${targetName}' is not inside the Stimulus controller '${controllerId}' I wonder if there's a way to handle this? Or is there an idiomatic Stimulus way of not doing what we're doing? As far as I understand the above is valid in Stimulus world, but I may be wrong.

[leonvogt]

Hi @DawidJanczak,

Sorry for the delay in responding. You’re right, this warning can be quite inaccurate. I've been experimenting with a way to mute certain warnings, but I guess that would also not be a good solution in your case.

A better option might be to improve detection so the warning only appears if the controller is actually present in the DOM. Would that solve your issue?

Or is there an idiomatic Stimulus way of not doing what we’re doing?

From my perspective, your usage is perfectly valid and reasonable in Stimulus. There's no need to conditionally set data attributes depending on controller presence.
Ideally the dev tools should be smart enough to handle this.

Thank you very much for bringing it up!

[DawidJanczak]

Yeah changing that detection would absolutely work for us, thanks!

[leonvogt]

Oh, my bad! I should have double checked the code more carefully.

A better option might be to improve detection so the warning only appears if the controller is actually present in the DOM.

That’s actually already how it works today: the warning is shown only if the controller exists somewhere in the DOM.

So in your case, if you’re seeing the warning for foo, it means a foo controller is indeed present somewhere in the DOM, just not wrapping the [data-foo-target='input'] element.

This makes it a bit more difficult to solve it.
I actually don't have a good solution for this right now, since I don't see a way to differentiate if the controller isn't wrapped around the target by purpose or by mistake.
One idea would be to add a way to mute certain warnings. But I see that this is not a perfect solution either.

If you have any ideas on how to improve this, please let me know.

[DawidJanczak]

Got it, thanks for the clarification!

That's correct, just to expand on why we have it like this: we have a certain piece of functionality that's on the main HTML body for desktop, but on mobile we render it in a separate modal window. We want to reuse the HTML and Stimulus controller in both places.

In effect this leads to a double error: on the desktop section in the HTML we're getting is not inside <mobile> controller and on the mobile section in the HTML we're getting is not inside <desktop> controller. Perhaps one way to handle this would be to check along the lines of "if target isn't inside controller here, but is inside controller elsewhere in the DOM then it's fine"? I realize that's pretty complex though and potentially not something worth complicating the code base for.

Also not sure how other people approach such scenario, perhaps there's better ways to write it.

[leonvogt]

Perhaps one way to handle this would be to check along the lines of "if target isn't inside controller here, but is inside controller elsewhere in the DOM then it's fine"?

I like the idea, but IMO we still can’t always be sure whether the target was left outside the controller on purpose or by mistake. Right now, I don’t see a reliable way to handle that scenario, sorry about that.

I'm working on a browser dev tools panel where the plan is to add a dedicated Warnings tab. There we could configure how warnings behave, for example which ones should still log to the console and which ones to silence.

Until that's ready, though, I'm afraid I don’t have a great workaround.

[DawidJanczak]

Understood, thank you for the update :)