This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-17
Channels
- # admin-announcements (1)
- # aleph (1)
- # architecture (1)
- # bangalore-clj (14)
- # beginners (15)
- # boot (89)
- # braveandtrue (1)
- # cider (1)
- # cljs-dev (33)
- # cljsjs (1)
- # cljsrn (147)
- # clojure (149)
- # clojure-quebec (1)
- # clojure-russia (82)
- # clojure-spec (18)
- # clojure-taiwan (2)
- # clojure-uk (15)
- # clojurescript (97)
- # cursive (11)
- # datomic (22)
- # funcool (2)
- # hoplon (53)
- # immutant (16)
- # jobs-rus (8)
- # lambdaisland (1)
- # off-topic (13)
- # om (7)
- # onyx (58)
- # parinfer (6)
- # planck (19)
- # protorepl (2)
- # re-frame (17)
- # reagent (201)
- # rum (6)
- # specter (9)
- # test-check (68)
- # untangled (47)
- # yada (94)
slightly off topic: my production javascript files are being cached, so that when I deploy a new app, the clients load stale SPAs until they invalidate their cache, any suggestions? I see wrap-not-modified middleware is in place https://github.com/untangled-web/untangled-server/blob/master/src/untangled/server/impl/components/handler.clj#L164 i thought that this handled cache invalidation, but I guess not
i know one of the main solutions is to append version number to JS filename / as a query param
Maybe hacky, but what we've been doing is linking to all assets with a git tag in the url (like: ["/assets/" :asset-tag "/application.js"]) which we under the hood just ignore and rewrite to /assets/application.js
So then we can make the caching headers far-future
Because every deploy will change it
Technically clojure doesn't know that the asset-tag is a git sha - we set it as an environment variable in our deploy setup, but not sure if that's really a detail that matters other than it made it easier to script than requiring a git clj library
Yeah, whatever wouldn't change - our deploy is currently git dependent, so that seemed like a reasonable approach.
Making it environment variable based did make it a lot easier to mess around with to test it was working as expected (and let us set a development only tag "0" that doesn't get caching headers).
what's weird to me is that i thought wrap-not-modified middleware looks at the timestamp of the file on disk, and compares that timestamp of file on clients disk
i find it strange that this hack is required at all, that a ring server can't work with the client to invalidate files that have changed on the server
Relying just on not-modified requires a round trip to the server every time, which is why we also added Cache Control headers for our tagged requests
Looks like wrap-not-modified still wants you to do the heavy lifting anyway
"Middleware that returns a 304 Not Modified from the wrapped handler if the handler response has an ETag or Last-Modified header, and the request has a If-None-Match or If-Modified-Since header that matches the response" ^ so you have to put your own ETag and Last-Modified values into headers for it to work
Though you'd think the middleware for serving static assets would do that
Yeah, we set it up the way we did so we can make max-age a year so it never has to check in
(Unless you reload and the html links to a new js file)
For anyone that has had problems with rendering and post-mutation (on data loads): I think I discovered a bug where post-mutations are not causing re-renders. I'm going to fix it (for now) by forcing a root re-render in the app when there are post mutations. This will be in 0.5.5-SNAPSHOT shortly.
Is snapshot going to release at some point? I know there was another fix on there for https://github.com/untangled-web/untangled-client/issues/21
Ah, I see.
alpha42 should fix that, which will let us clean up some code and have that work (hopefully)
My understanding is that this is actually a bug in Closure we're working around until it gets fixed.
Wow, the rabbit hole goes even deeper than I realized.
@therabidbanana: see https://github.com/omcljs/om/issues/729 for more info