Why can't turbo-frame responses use morphing?

[olly-chadwick-carwow]

I think I'm right in saying that turbo doesn't allow users to handle Turbo Frames using morphing/idiomorph. If this is the case, I'm wondering why this is. Are the reasons:

• technical (it would be hard/impossible to do)?
• principled (this is not the way the library should be used)?
• or is it simply that this is a low priority/niche feature which no-one has requested yet?

If the latter, then perhaps I can explain my own use case.

Use case

On a product listing page, I have a "turbo frame" filters panel. When a user selects one of the filters, the page is updated and the panel updated. When the page is viewed on mobile, the filters panel covers the entire page, and the scroll state of the panel element is important.

Currently when a filter is selected and the filters panel turbo frame is re-rendered, the entire content of the panel is replaced and the scroll state is lost (focus jumps back up to the top of the page). If I could use morphing when rendering the turbo frame, then only the elements of the filters panel that had changed would be re-rendered on the page, and the scroll state of this element would be preserved.

There are certainly other ways of achieving the same thing. For example, I am currently implementing the filters panel using turbo-streams (which do allow for morphing), and I would also like to try redoing the page using turbo-drive (which also allow for morphing).

However, I am curious as to why morphing is restricted when it comes to turbo frame responses.

Many thanks!

[4lllex]

Any reason you have your filters inside the frame? Normally, you'd put filters/search form outside of the frame so its state is preserved and only update the frame with the results.

Turbo frames can be morphed on refresh, although src attribute seems to be required for this, or you can diy any other rendering: https://turbo.hotwired.dev/handbook/frames#custom-rendering

[tom-lord]

Any reason you have your filters inside the frame? Normally, you'd put filters/search form outside of the frame so its state is preserved and only update the frame with the results.

That's only true for a relatively 'basic' (static) filters design.

A more advanced filters UI can change dynamically, based on whatever is currently selected by the filters. For example:

• Filters might display the number of results, before you click them
  • E.g. On hotel booking sites, you might see "how many results you'll get by adjusting the price filter", before you actually change the price filter.
• A filter might be shown/hidden, based on whatever else is selected.
  • E.g. On a car site, a "hybrid type" sub-filter might only become visible when "fuel type: Hybrid" is selected.
• Each available filter options might change dynamically
  • E.g. On a clothing site, the "available sizes" in the filter menu might depend on the item(s) being filtered for.

So in other words, each time any filter is changed, the page needs to refresh the filters panel and the results panel.