Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't reload stimulus controllers after morphing
There was a flaw in the implementation: we wanted to reload the stimulus controllers when their element was effectively morphed because some attribute had changed. Our implementation was essentially reloading all the stimulus controllers instead. But, even if we implemented our original idea, we have changed our mind about it being the right call. The heuristic of "reload controllers when some attribute changed" came from some tests with legacy controllers that used dom attributes to track certain conditions. That doesn't seem like enough justification for the original idea. In general, you don't want to reload controllers unless their elements get disconnected or connected as part of the morphing operation. If it's important for a given controller to track changes to the dom, than it should do that (e.g: listening to connection of targets or outlets, or just with the mutation observer API), but we can't determine that from the outside. If we introduce some API here, it will be the opposite: an API to force a "reconnect" during morphing, but we need to see a real justification in practice.
- Loading branch information