Skip to content
This repository has been archived by the owner on Nov 8, 2017. It is now read-only.

App cache development issues. #37

Open
Fishrock123 opened this issue Jan 31, 2014 · 8 comments
Open

App cache development issues. #37

Fishrock123 opened this issue Jan 31, 2014 · 8 comments

Comments

@Fishrock123
Copy link
Contributor

However its caching things I can't clear it as normal, and my local index.html refuses to refresh in chrome.
@artursapek
Copy link
Owner

Locally? On prod? index.html shouldn't be cached at all. https://github.com/artursapek/mondrian/blob/master/app/mondrian.appcache

@Fishrock123
Copy link
Contributor Author

My web browsers don't seem to care. Are you sure <html manifest="/app/mondrian.appcache"> doesn't also cache the html page its on?

@artursapek
Copy link
Owner

Positive, just checked. Try changing the contents of the mondrian.appcache file and refresh the page twice. If that still doesn't work, there's a problem, in which case you can clear the appcache in chrome://appcache-internals/.

@Fishrock123 Fishrock123 mentioned this issue Feb 1, 2014
Closed
@artursapek
Copy link
Owner

Turns out you're right. I missed this the first time I read this article:

The HTML page itself isn’t listed in the manifest. Pages that associate with a manifest become part of it.

Yesterday I did a lot of work to clean up the repo. I also simplified the build/dev process; all files are now compiled with cake build and none of the compiled files are tracked. So please update your master before you start new branches.

I have two more things I want to do in this area, one of them addressing this issue:

1. Speed up the compilation to under 3 seconds. (#25)

2. Automate updating the .appcache file with an md5 hash of the current time or something (thus invalidating the cache), with every cake build or change to index.html (matter of fact, that file should also be in HAML, and it should also be compiled with cake build). This way new commits will always invalidate the cache, and development won't be a pain in the ass.

This means commits will always have to include changes to this file, which kind of sucks, but I can't think of a better solution besides removing the appcache entirely, or .gitignoring it and somehow generating it when someone first forks the repo.

Appcache was designed exactly for apps like this, so I'd like to keep it if possible.

How does that sound?

@artursapek
Copy link
Owner

Appcache is more of a douchebag than I realized. For instance, I just deployed the tooltips feature. Given how appcache works, when I refreshed production for the first time the CSS and JS was updated but index.html wasn't - it was pulled from the cache. Since I changed how the tool buttons are identified in the CSS, they all showed up empty with no icons inside.

After I refreshed a second time, since appcache knew at this point that the cache had been invalidated, the new index.html was pulled down.

That means that all the cached files are not invalidated at the same time. All returning visitors will have to get a page load where all the tool icons are empty. If you ask me, that's plain stupid.

Seriously considering forgetting about the whole thing and removing it; so far it has given me way more trouble than it's worth.

@jokeyrhyme
Copy link

If the request for the manifest responds with a 404, then the browser will disable AppCache behaviour. So, what you may be able to do is temporarily hide or remove the manifest file when you are doing upgrades, then put it back once you're happy with the behaviour.

Also, there are JavaScript events for AppCache. So you may be able to ask the user to refresh the page or something when the manifest has changed.

@artursapek
Copy link
Owner

Well hopefully the app continues to be actively developed and I deploy to production frequently, so there won't be a point where I'm happy with the behavior for good.

I'd like appcache to always be there, but it works in a way that sucks and makes it unviable. I can't have users coming back and getting updated versions of certain pages and old versions of the html page. That's nuts. Deploys shouldn't break the experience.

I may be misunderstanding something, but from what I've read so far this behavior is intentional and mandatory. I'll do more research, but appcache may have to go.

@Fishrock123
Copy link
Contributor Author

I personally am in favour of dynosrc-esque style "cache"s.

http://dinosrc.it/

I.e. don't just suppose a cached asset is valid for the given duration, check the SHA's with the server, download changes, not new files.

@Fishrock123 Fishrock123 mentioned this issue Feb 6, 2014
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jokeyrhyme @artursapek @Fishrock123