This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-31
Channels
- # announcements (3)
- # beginners (139)
- # boot (28)
- # cider (40)
- # cljdoc (1)
- # cljs-dev (30)
- # clojure (61)
- # clojure-conj (1)
- # clojure-dev (113)
- # clojure-germany (4)
- # clojure-italy (29)
- # clojure-nl (3)
- # clojure-russia (2)
- # clojure-spec (38)
- # clojure-uk (53)
- # clojurescript (188)
- # core-async (4)
- # css (2)
- # cursive (7)
- # data-science (5)
- # datomic (14)
- # emacs (1)
- # figwheel-main (192)
- # fulcro (37)
- # jobs-discuss (1)
- # mount (4)
- # off-topic (47)
- # pedestal (7)
- # portkey (14)
- # re-frame (4)
- # reagent (22)
- # reitit (2)
- # remote-jobs (1)
- # ring (6)
- # shadow-cljs (65)
- # spacemacs (7)
- # specter (6)
- # yada (8)
what's the point of using :as
if the original namespace is the same as the alias, like [router5 :as router5]
?
Excellent question, I saw that somewhere and copied the style but didn’t verify that’s different from just [router5]
I hope it's not different, because that would suggest some kind of unintuitive magic going on behind the scenes.
you're right, it seems equivalent
Unfortunately .default
is still needed here: https://github.com/pesterhazy/cljs-spa-example/pull/4/files#diff-2249f4775fc4a650d6967a94bb96deecR39
honestly I haven't fully grokked that part. Why do you need require("foo").default
, and sometimes not?
I fixed up my figwheel.main+devcards example project. It works as expected now. https://github.com/onetom/clj-figwheel-main-devcards
I created an issue to clarify my recent adv-comp type annotation question: https://github.com/clojure/clojurescript-site/issues/260
Running into an issue with the test runner. On this branch: https://github.com/pesterhazy/cljs-spa-example/pull/11/files, when I open the page initially, it looks like no tests are registered. When you reload (or clear the cache), that doesn't help. But when you touch the cljs file containing the tests, they get registered properly
@pesterhazy you need to use the async support in cljs.test as well or there is no test finished signal
@bhauman I don't think that's it. The async test is commented out, plus I reimplemented what cljs.test/async does in the promise-test
fn: https://github.com/pesterhazy/cljs-spa-example/pull/11/files#diff-26c35a846286dd881684332ac2e68d68R6
@pesterhazy you have clojure.test/IAsyncTest not cljs.test/IAsyncTest
clojure.test is an alias for cljs.test, so they should be equivalent, no?
ah I found a way to reliably repro the issue
- start/dev - see the test show up - change the name of a test, arithmetic-test-expected-to-fail -> arithmetic-test-expected-to-fail-2 - the reload
expected result: you see the new test
actual result: the renamed test isn't found
until you Shift-Reload
so it must be related to browser caching...
when I restart the figwheel process, that doesn't have any effect
@pesterhazy it looks correct
Look in the console and see if when you change the test file, if the test runner is reloaded
I can even run scripts/dev --reset
, and it's still empty unless I shift-reload
not sure I understand the question. Tto repro the issue I'm clicking the Reload button in the browser, so fighweel-reloading isn't involved
i'll try with just clojure.test/run-tests
yeah?
removed the reference to cljs-test-display and push my changes
same problem
again what I did was to change the name of the single test, then reloaded
once I shift-reload, it works again
oh yeah?
right
the first time I ran into this, I was manually reloading because I wasn't sure if some change I made was taking effect
based on the assumption that a manual Reload usually fixes things
in this case, though, after renaming the test figwheel's live reloading gave the correct result
but manually reloading didn't - which is what was confusing me
my thinking is, if it's fixed by Shift-Reload, it must be caching, no?
and specifically Chrome's cache (not anything in Figwheel's internal state)
not sure I understand that question
and I’m wondering when you have these cache hit situations if you are getting the same result you get when the page first loads
One thing that needs to be remembered here is that the run-tests
macro is super funky
if you look at the compiled test runner you will see a list of all the tests that it was able to find at compile time
that's what you see when you reload
core_test.js is reloaded properly (I can verify if I look at the file)
but test_runner.js isn't
which, as you say, contains references to the tests function names in cljs-spa.core-test because of the run-tests macro
its caching the artifact at some time z, and you are getting that cached artfact no matter what’s been hot reloaded
I think it must be the If-Modified-Since: Fri, 31 Aug 2018 12:11:04 GMT
Request Header
If I right this correctly, Chrome is not sending an Etag in the request
https://github.com/deps-app/ring-etag-middleware/blob/master/src/co/deps/ring_etag_middleware.clj
does that middleware take into account the If-Modified-Since
header?
right
in the case, though, I think the problem lies with the Last-Modified response header the server sends back
my hypothesis is some component uses the last-modified time of test-runner.cljs
to determine the LastModified
header of the response of test_runner.js
but that's not necessarily correct - the js output should change if the source cljs file gets modified, but also wgeb any of the dependencies is modified
something to know is that the time of modification of the input cljs files and ouput js files is kept in sync
@danielcompton you should be included in this conversation
Well this is enough information to track this down. It does seem like excluding last modified headers makes sense if we are including etags
but I’d have to defer to @danielcompton on this because he has put a lot of thought in to how to make this behave correctly
No problem
Just tried in Chrome Canary, regular Chrome and Firefox - all incorrectly get a 304 Not modified
Do you want me to file an issue?
@bhauman looks like the figwheel server uses 2 different middlewares, not-modified and etag. If I'm not mistaken, the faulty header is generated by the not-modified wrapper, not the etag one
even though the If-None-Match
header sent by Chrome is out of date, the server still returns a 304
because the If-Modified-Since
request header matches the file's last-modified date
one solution would be to remove the not-modified
middleware, or to strip out the Last-Modified
header from the response (it's not needed because the response already contains the ETag)
is the hot reload why the last modified header is the same? and the the browser is fetching something older than the hot reloaded code from its cache?
the Last-Modified response header matches the mtime of the cljs file
right, only the macro expansion changed
yeah, caching is the worst
https://github.com/ring-clojure/ring/blob/1.6.1/ring-core/src/ring/middleware/not_modified.clj#L36
@pesterhazy ok the not-modified middleware doesn’t add the last modified head but it does return the 304
I wonder if that or
is correct
if the Etag doesn't match, it still considers the resource not changed
there are 3 cases, Request-has-Etag and matches, Request-has-Etag and mismatches, and Request-has-no-Etag
in the 2nd case, the response should be considered modified
I'll submit a PR to the middleware
well the good news is that the etag approach is correct and that the not-modified code is at fault
I think so
@pesterhazy if he isn’t responsive, the code is simple enough to include in figwheel
>>> A recipient must ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.
re: the case where both headers are specified
from RFC 7232
so the logic should be 304 if etags are provided by request and response, and they don’t match
@danielcompton is way ahead of us
that's good news, isn't it? that's already in ring master
so upgrading to 1.7.0-RC2 should be sufficient: https://github.com/ring-clojure/ring/commit/95e4ca25d5b98c45f927b32b5c3c85c21c999d96
can confirm that adding
ring/ring-core {:mvn/version "1.7.0-RC2"}
to deps.edn fixes the issuethanks for helping me understand this
what's the downside of doing that?
ah I didn't know that jetty had changed so much
what happens is jetty is broken in to many many parts and the all have the save version number
gotcha
alternatively like you said making a copy of the ns, https://github.com/ring-clojure/ring/blob/95e4ca25d5b98c45f927b32b5c3c85c21c999d96/ring-core/src/ring/middleware/not_modified.clj#L53 should be trivial
yeah its a trade off, let me look at the commits of 0.1.7-RC2 and see if any prs are really relevant
@bhauman So Jetty guys have botched the rule "unit of reuse is unit of release" and chopped it thinner than it should be?
and if the versions were different across the whole release it would drive someone insane
I wonder if one can do something like Conflicts: jetty-something (!= 1.2.3)
(in maven?) so that these errors surface immediately.
So that all parts of jetty would conflict with other parts of jetty with non-matching version.
So is everything sorted here now?
Might be useful if it hasn’t been mentioned