Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fighting the browser cache in deployed websites #385

Open
rallisf1 opened this issue Apr 25, 2024 · 3 comments
Open

Fighting the browser cache in deployed websites #385

rallisf1 opened this issue Apr 25, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@rallisf1
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Many browsers (especially chrome mobile) don't respect the caching TTL set by hosts. This leads to changes made in existing symbols to not be visible by guests, even after that TTL, unless they clear their browser history.

Describe the solution you'd like
Add the build time timestamp as a file suffix on exported _symbols.

Describe alternatives you've considered
I am currently either duplicating symbols, so their id changes, which is not that helpful when being used in many pages; or setting a no-cache, no-store, must-revalidate Cache-Control header on the host.

@mateomorris mateomorris added the bug Something isn't working label Apr 25, 2024
@MentalGear
Copy link

would you be able to add a PR for this?

@rallisf1
Copy link
Contributor Author

rallisf1 commented Nov 4, 2024

would you be able to add a PR for this?

I don't think there will be any new commits/PRs to this puppy. I'm using it as it is for now, probably will do a hard fork next year.

@MentalGear
Copy link

MentalGear commented Nov 4, 2024

Really unfortunate: such a great idea and so much potential and energy already put into it, but very understandable as open-source economics are really tough to figure out. This would have needed some kind of supabase-branded CMS kickstarter or so to get it rolling in the same FOSS spirit.

PS: I'm wondering if Primo v.2 would be eligible for the new Sveltehack 2024 contest (previous winner Superforms), certainly could bring much value to the Svelte community, but it's just not known enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants