Might be best left to turbolinks, although there is no movement on them ever implementing this.

See: https://gist.github.com/hopsoft/ab500a3b584e2878c83137cb539abb32 && turbolinks/turbolinks#313

I am seeing it as a data-trimmings-prefetch="true" or similar.

Looking through the autosubmit and the replace javascript.

Wondering how to best write a "search" feature.

How I'd like it to work: On input change, submit the form, and replace the dom section. I also have a couple of checkboxes that I'd like to do the same thing.

The embed feature does not fetch an embedded link if the <a> has the display: none; property, which is handy for avoiding extraneous network calls on mobile devices, for example. If one of these links is revealed after the DOM is loaded as the result of a media query, it should be detected and fetched.

Note that we already listen for orientationchange events, so we just need to handle viewport size queries.

The tests run in Chrome and I've done plenty of testing manually in Safari and Firefox, but we should make sure this works in IE11 and Edge as well.

Is there a significant difference between these two features? I was trying to understand the difference but it's not clear to me from the docs. They seem to serve a similar purpose which is to inline content.

Maybe the Remove feature could be extended to accept a delay value:

<button data-trimmings-remove=".modal" data-trimmings-remove-after="5">
  Close modal
</button>

If no delay value is provided it waits for a click (current behavior). If a delay value is provided it removes the element after the delay time, whether a click was detected or not. Great for automatically dismissing notifications.

Similar to what @snellingio mentioned in #1

Unsure if this is supported, it might already be by adding css classes.

If so, we should document how to use them. I can see wanting to transition both the content (think counter) and the content area (think modal)

Holding a modifier key while clicking a link—i.e. holding cmd to open it in a new tab—should disable any Redact hooks and allow the link to work naturally. Turbolinks's clickEventIsSignificant check is a good model to follow here.

Automatically interact with something after a specified duration, or when it comes into view. Useful for automatic data refreshes and infinite scroll.

• What should this be called? "Autoclick" works for links and buttons but we should allow form submission as well. Maybe just "Auto?"
• Should we consider time-based and visibility-based interactions to be two options of the same feature, or two different features?

See #1

I would like to see an option to refresh a section every X (where X is in ms, sec, or minutes).

Would essentially be a long polling feature.

Is it OK to use Trimmings with Turbolinks and Stimulus in the same project? Any known conflicts?

Add a feature that listens for swipe gestures and clicks/submits the targeted element.

<div 
  class="deck-slide"
  data-trimmings-swipe-right="a.next-slide"
  data-trimmings-swipe-left="a.previous-slide"
>

I know that adding -trimmings to all the data elements namespaces it nicely. However, it seems a bit silly to write -trimmings on every data element. data-inline or data-replace seem like that wouldn't collide with anything anyways.

Same thing goes with writing css classes with trimmings in them (on the enabled and on the current feature).

Maybe there is a happy medium to be had here.

If not, feel free to close. Just thinking out loud.

I'd like to create a dropdown with the Toggle feature. However, the toggle will remain open on hitting the back button with Turbolinks. Using stimulus and turbolinks, I'd normally either remove the node or add / remove a class.

Maybe there is room for a before cache feature? Or alternatively, maybe an event feature might keep it more flexible?

Presently you have to duplicate where you want to load from and to for the inline feature:

<a
        data-trimmings-inline="from: main, to: main"
        href="/cake"
      >
        Cake
      </a>
... etc
... etc

This can get pretty repetitive if you serve just a partial from the server of the exact element to be replaced.

So it would be great if the from and to were both optional and infered based on the top-root element in response from the server.

For example:

<a
        data-trimmings-inline
        href="/cake"
      >
        Cake
      </a>

Response from server:

<main>.....</main>

Trimmings will assume from: main, to: main

Another example:

<a
        data-trimmings-inline="to: custom-main"
        href="/cake"
      >
        Cake
      </a>

Assuming the same response from the server <main> trimmings will essentially assume:

from: main, to: custom-main

Currently, there is a "trimmings-loading" class on both the embed and the inline feature.

Would like to see a "saving" class on the autosubmit, as well as a "loading" class on the inline.

I'd personally like to see something like nanomorph brought in as a replacement method for both inline and replace.

Totally understand if you do not want to add another dependency or more surface area.

When features that involve fetching external documents receive unexpected responses, their behavior should change. Generally, this means that they should fall back to working like regular, unenhanced links and forms.

For example, if an inline link fetches a URL that returns a response with a status code in the 400 or 500 range, it should just display the full response as if the user clicked a regular link, as we cannot ensure that the targeted elements actually exist on the page or that the fetched content can reliably be rendered on the current page. An embed that returns a 400+ response should do nothing, leaving the enhanced link on the page for the user to click if they so desire.

300 requests should probably be followed, which is the default behavior when using fetch, so there's no work to be done here.

Reference this line and serialize import:

If the element is a form then couldn't this just be simplifed as new FormData(element) and pass that onto fetch ? There's no need to manually serialize form and it's elements...

Currently, an inline-enhanced form will only submit data as application/x-www-form-urlencoded. It would be nice if Trimmings would respect enctype and submit multipart forms appropriately.

I'm super stoked about this project, but a bit confused about how to use it!

• The installation says "just include trimmings.js in your " But the only spot I see a trimmings.js file is when I look at the code over on glitch
• The Getting Started is more like background; it doesn't quite explain how to use Trimmings.

I hope this can get a bit more user-friendly, because I loooooove the idea and the background behind it. Y'all rule!

The arguments "to" and "from" work the other way around (unlike in the documentation)
It should be like that:

• from: A selector targeting the linked page where our content will come from. (required)
• to: A selector targeting an element in the current document where our content will be inserted. (required)

(Thanks for making trimmings, it's great!)

It would be great if we could configure the ajax/fetch requests to include additional information, a bit like axios config defaults

Our use case is that we want to add a custom header X-Requested-With-Trimmings that way we can detect this on the server and only serve partial HTML if we know we don't need to render the full page.