You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been converting an app (a newsletter editor that shows changes to the newsletter in realtime via Turbo Streams) to use morphing page updates (for other users) and targeted turbo stream updates for the initiating user.
There are various interfaces in the newsletter such as image panning, dropdowns, colourpickers and a modal interface for the more complex forms. I've found I need to inhibit morphing a lot when these interfaces are active. It's simple for the modals as we never want these to be morphed so we end up with this in initialise() {}:
Sometimes I just don't want something to revert to its default state (e.g. a dropdown menu should stay open even if its content changes due to a morph:
I don't know about you, but I can start to see an interface developing here and I wondered if it might be time to build some of this into Stimulus? Of course I can't really see beyond my use cases but I can see perhaps some helper functions like so:
preventElementMorph() // On the controller element
preventElementMorph({target: 'button'}) // On a target element
preventAttributeMorph({classContains: 'is-active'}) // On the controller element
preventAttributeMorph({target: 'button', classContains: 'is-loading'}) // On a target element
I can see some flaws there. Perhaps you'd want to prevent an element morph if a class exists. Perhaps you'd want to be more targeted in what attribute you'd want to prevent the morph of.
I'm hoping this can act as the start of a discussion given morphing and its side effects have now turned succinct Stimulus controllers into a bit of a mess.
The text was updated successfully, but these errors were encountered:
I've been converting an app (a newsletter editor that shows changes to the newsletter in realtime via Turbo Streams) to use morphing page updates (for other users) and targeted turbo stream updates for the initiating user.
There are various interfaces in the newsletter such as image panning, dropdowns, colourpickers and a modal interface for the more complex forms. I've found I need to inhibit morphing a lot when these interfaces are active. It's simple for the modals as we never want these to be morphed so we end up with this in
initialise() {}
:Sometimes I just don't want something to revert to its default state (e.g. a dropdown menu should stay open even if its content changes due to a morph:
I prefer to add the listener to the controller element, but sometimes we care about inhibiting on another target inside the controller:
I don't know about you, but I can start to see an interface developing here and I wondered if it might be time to build some of this into Stimulus? Of course I can't really see beyond my use cases but I can see perhaps some helper functions like so:
I can see some flaws there. Perhaps you'd want to prevent an element morph if a class exists. Perhaps you'd want to be more targeted in what attribute you'd want to prevent the morph of.
I'm hoping this can act as the start of a discussion given morphing and its side effects have now turned succinct Stimulus controllers into a bit of a mess.
The text was updated successfully, but these errors were encountered: