Introduce client-side Turbo Cache Control API #632
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit introduces a `Cache` class which exposes an API that can be used to control the value of the `turbo-cache-control` meta element form the client-side. Most of the times you just need to the set the value of the `turbo-cache-control` meta element from the server-side when you are responding to your regular HTML request. But there are some cases where you want to control the cache control behavior from the client-side after a certain action happened on the client (i.e. if you don't want to show remaining artefacts of an finsihed animation). You can achieve the same behavior by dynamically prepending a `<meta>` element to the `<head>` via JavaScript, like: ```javascript document.head.insertAdjacentHTML( 'beforeend', '<meta name="turbo-cache-control" content="no-cache">' ) ``` Though, this feels very error-prone and doesn't account for duplicate `<meta>` elements in the `<head>`. This Pull Request aims to simplify this by exposing a client-side API to control the value of the meta element. The name of the exposed functions are kept in-line with the helpers in: https://github.com/hotwired/turbo-rails/blob/43bf84a9b1d2cc78da6810b82f92be2c32c9dbfd/app/helpers/turbo/drive_helper.rb#L15
marcoroth
force-pushed
the
client-side-cache-control-api
branch
from
33d80ff to
ad93db2
Compare
|
I think what you've presented here is the right trade-offs. Gathering all this in a class provides a nice namespace, and the clearer names that include page are easier to understand the meta matching ones. |
|
Should get a doc PR going for 7.2.0 release too. |
|
I will follow up with a doc PR 👍🏼 Should we deprecate |
|
Yes please 👍 |
marcoroth
added a commit
to marcoroth/turbo
that referenced
this pull request
Jul 18, 2022
In favor of `Turbo.cache.clear()`. Related: hotwired#632
marcoroth
added a commit
to marcoroth/turbo
that referenced
this pull request
Jul 18, 2022
`Turbo.clearCache()` is depreatec in favor of `Turbo.cache.clear()` Related: hotwired#632
marcoroth
added a commit
to marcoroth/turbo
that referenced
this pull request
Jul 18, 2022
`Turbo.clearCache()` is deprecated in favor of `Turbo.cache.clear()` Related: hotwired#632
marcoroth
added a commit
to marcoroth/turbo-site
that referenced
this pull request
Jul 18, 2022
dhh
pushed a commit
that referenced
this pull request
Jul 18, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This Pull Request introduces a
Cacheclass which exposes an API asTurbo.cachethat can be used to control the value of theturbo-cache-controlmeta element form the client-side.Most of the times you just need to the set the value of the
turbo-cache-controlmeta element from the server-side when you are responding to your regular HTML request, based on if you want that page to be cached or not.I encountered a few use-cases in a couple of apps I worked on where you dynamically want to set the cache control behavior after a certain action happened on the client (i.e. you don't want to show remaining artifacts of a finished animation in a later visit, but if the animation wasn't triggered you still want that page to be properly cached).
You can achieve a similar behavior by dynamically prepending a
<meta>element to the<head>via JavaScript, like:Though, this feels very error-prone and doesn't account for duplicate
<meta>elements in the<head>.This Pull Request aims to simplify this by exposing a client-side API to control the value of the meta element with just the values Turbo actually knows about. With that, the above example becomes:
The name of the exposed functions are kept in-line with the helpers in:
https://github.com/hotwired/turbo-rails/blob/43bf84a9b1d2cc78da6810b82f92be2c32c9dbfd/app/helpers/turbo/drive_helper.rb#L15-L23
Open Points / Design Decisions:
Introducing a
Cacheclass and exposing an instance of said class asTurbo.cachemight be overkill. It might be just fine to instead add the helpers as top-level functions, similar as with theTurbo.clearCache()helper.Turbo.cache.exemptPageFromCache()=>Turbo.exemptPageFromCache()Turbo.cache.exemptPageFromPreview()=>Turbo.exemptPageFromPreview()The helper names
exemptPageFromCache()andexemptPageFromPreview()don't exactly line up the with attribute values.Turbo.cache.noCache()/Turbo.cache.noPreview()