This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (36)
- # boot (1)
- # cider (4)
- # cljsrn (2)
- # clojure (137)
- # clojure-brasil (3)
- # clojure-czech (3)
- # clojure-italy (17)
- # clojure-nl (8)
- # clojure-spec (7)
- # clojure-uk (153)
- # clojurescript (84)
- # data-science (2)
- # datascript (13)
- # datomic (30)
- # editors (64)
- # emacs (22)
- # events (6)
- # figwheel (26)
- # fulcro (7)
- # hoplon (5)
- # jobs (5)
- # jobs-discuss (57)
- # keechma (3)
- # leiningen (4)
- # luminus (1)
- # midje (2)
- # off-topic (26)
- # portkey (18)
- # re-frame (4)
- # reagent (10)
- # ring-swagger (3)
- # shadow-cljs (135)
- # spacemacs (5)
- # sql (14)
- # tools-deps (125)
Wonder if React 16’s async rendering can help to achieve the same, disabling custom batching would finally remove numerous issues with input fields.
React async support will require rewrite of most React libs so it will take long time before that is usable
Yeah was going to say the same. It seems to be a very strict mode for components, mostly requires making them stateless.
I’ve seen there’s a new unstable method for performing deferred updates, similar to the old unstable_batchedUpdate
Here’s an example https://gist.github.com/threepointone/4a997107e758f67a90d2fbd4fb48b16a
From what I see it can be used to execute any code and let React’s rendering loop decide when to do it
I have started to write tests for my application written in Cljs targeting Nodejs. I have used core async pratically in every function and now I have discovered that the macro
with-redefs do not works well with async testing, in particular when inserted in a go block (in fact, it makes a permanent rebinding of the symbols (I am also curious to understand why)). On google I've find this macro that can resolve this issue,
(defmacro with-reset [bindings & body] (let [names (take-nth 2 bindings) vals (take-nth 2 (drop 1 bindings)) current-vals (map #(list 'identity %) names) tempnames (map (comp gensym name) names) binds (map vector names vals) resets (reverse (map vector names tempnames)) bind-value (fn [[k v]] (list 'set! k v))] `(let [~@(interleave tempnames current-vals)] (try ~@(map bind-value binds) ~@body (finally ~@(map bind-value resets))))))
but I wonder if it is the best practice or there is another way that is not use set! before and after each test. Thanks!
@giovaferra it's something I was bitten too by recently. AFAIU
with-redefs doesn't work as you expected in CLJS in
go-blocks due to the code transformation issue somewhere in
core.async. But this was not fixed because the core team says you should never use
with-redefs in any async scenarios in CLJS anyway: https://dev.clojure.org/jira/browse/CLJS-884.
I'm not sure I agree it shouldn't be fixed because async tests are usually called serially and in this particular case we are sure that it's safe to redefine the variable in all "threads". @dnolen proposed (https://clojurians-log.clojureverse.org/clojurescript/2017-03-22/1490194064.583172) to use explicit
set!s in async tests instead and semantically it's kind of same as wrapping with
with-redefs, so why not fix
with-redefs for usage in such serial tests?..
But I agree that using
with-redefs is a code smell, even in sync scenarios. The best way is to use explicit dependency injection instead of redefing the implicit dependency. @tbaldridge explains it well here: https://www.reddit.com/r/Clojure/comments/4wrjw5/withredefs_doesnt_play_well_with_coreasync/d6amwzz/
@giovaferra I wrote some ideas into readme here, I wouldn’t recommend using the project, because I don’t actively use it myself, but it could be an interesting read to understand bindings and async code  https://github.com/binaryage/cljs-zones
btw. if you are targeting recent nodejs, you could also look into https://nodejs.org/api/async_hooks.html
this is basically nodejs-specific-api for implementing something like zone.js (effectively)
@darwin thanks for the answer! I have read it and it is very interesting, I think that I have still a lot to learn, since many thing are still not clear to me 🙂 No, unfortunately I'm not using a recent version of Nodejs (and I can't update it 😞 ).
@bhauman I hadn’t heard reports of it working out well still at this point, so didn’t include that in the list.
I thought a bunch of node libs out there still failed to be compiled correctly under it due to various issues in cljs, but mostly in closure etc
Just ran into a case where requiring node modules via ns requires broke when switching branches
Yes switching git branches in the project. The error reported was this: https://github.com/bhauman/lein-figwheel/issues/576 @bhauman
But I couldn’t find any official documentation about this functionality.
I think it wasn't actually related to
:npm-deps. We don't use it. We only use ns requires, while running
npm install manually
my understanding of the new js import feature of the cljs compiler is imperfect, so I might be using them wrong
These are all points worth considering, and also if you have a workflow thats reliable and works for you, that's very important. Just don't want folks to just forget about it. It could still be helpful/simple in the early stages of a project.
Personally after the
node-postgres issue I haven't found much breakage. I am using node: it is probably easier to manage than browser and all its ways to load modules.
1.10.238 is still pretty bad in standard CLJS, see this recent log https://theiceshelf.com/log/2018-06-cljs-npm-deps/ (maybe
master is better though)
Does anyone have advice on integrating a library written in JSX with reagent/CLJS? Is using babel to compile to js modules a viable approach?
Yeah, reading that article was a little frustrating, seeing
_SINGLEQUOTE_ in the error message.
(Frustrating in the sense of seeing so much copy written, without being able to suggest, please remove the
' from your config.)
yeah the author obviously went through the Quick Start and then got caught on a trivial error - albeit an annoyingly common one
its really fascinating how that author dumped every thought as it happened. he or she had so many of the same thoughts i had when i first came to cljs (like, “In fact, it bugs me like a caterpillar that I still don’t really know what :cljsbuild is.“)
I just saw the seemingly common
Uncaught Error: Undefined nameToPath for react but yeah the other stuff are easy fixes. have them in my specs for configs as well. https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/shared.clj#L13-L19
I think there's plenty of feedback for npm-deps in that blog post too. While the stuff he had trouble with involving the new cli tools are more relevant to more recent work y'all are focusing on, it is frustrating still to see that the de facto standard for building CLJS apps right now could not do what he wanted (use the antd library) without quite a bit of work investigating and understanding the inner workings of clojurescript compilation
a significant amount of feedback about
:npm-deps at this point is not super helpful since nearly everything anyone might encounter is already known
at the same time people continue to complain about stuff they aren’t contributing too 🙂
as I’ve said on many occasions if more people don’t work on the problem - you should expect progress to continue be slow but steady
just reiterating that nothing is going to change any quicker unless people work on it
Some of the
:npm-deps stuff may require us contributing as a community to Closure as well (because the compiler relies on it for certain aspects)
is there a walkthrough of what
:npm-deps internals are doing and/or what the design principles are? (besides the not-an-island article)
we resolve the node_modules dependency graph and make sure they are passed as inputs to Closure Compiler along with your own stuff
welp trying to use Webpack to test something - this ain’t any easier than ClojureScript that’s all I gotta say
modern JS development seems about as straightforward as wrangling Maven - sans XML and the information seems outdated