Clojurians Log v2

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

nice like it

thanks

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

right, yah, i would be very hesitant to add a dependency on git

you could even do md5sum of the jar file and pass that as env var

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

and that this would invalidate the cache if I modified my javascript file

maybe i don't understand the middleware well enough

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

ok I think I get it now

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

that's assuming the client even makes a request for a file it has cached

which I guess it will only do once TTL has been reached

the max-age value

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.

That fix has been pushed to clojars on the snapshot

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

advanced optimizations is still not quite right with Om itself

The fixes going on there will affect that, I believe

Ah, I see.

(and will affect our implementation)

basically anything declared "static" is getting killed by Closure

alpha42 should fix that, which will let us clean up some code and have that work (hopefully)

for now, use whitespace or simple

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

wow, nice

can I call load-field-action twice in the same mutation handler?

to load 2 different fields

yes

it just appends a load onto the sequential queue

perfect

the thing you pass to :remote triggers an attempt to process it

ahh