Fork me on GitHub
Roman Liutikov06:06:09

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

Roman Liutikov07:06:59

Yeah was going to say the same. It seems to be a very strict mode for components, mostly requires making them stateless.

Roman Liutikov07:06:39

and no deprecated lifecycle methods


But yes, hopefully that will solve problems with inputs and async rendering

Roman Liutikov07:06:12

I’ve seen there’s a new unstable method for performing deferred updates, similar to the old unstable_batchedUpdate

Roman Liutikov07:06:07

From what I see it can be used to execute any code and let React’s rendering loop decide when to do it


Hello everyone! 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)]
         ~@(map bind-value binds)
           ~@(map bind-value resets))))))
from 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: 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 ( 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:


Thank you so much.


@giovaferra I wrote some ideas into readme here[1], 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 [1]


btw. if you are targeting recent nodejs, you could also look into


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


I’d be pretty excited to see the built-in :npm-deps become the way to go


It still has rough edges for sure


what do you mean? switching git branches?


but you have been using :npm-deps otherwise?


Yes switching git branches in the project. The error reported was this: @bhauman

replied to a thread:

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


and foreign-libs


@bhauman no not directly (but presumably indirectly through cljsjs)


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.


It would be really nice if we could rely on it


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.


Oh yay! :npm-deps is now live? I’ll be kicking the tires of that 🙂!


FWIW :npm-deps in 1.10.238 is still pretty bad in standard CLJS, see this recent log (maybe master is better though)

😱 4

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?


Anyone have any idea what this error means:


I'm trying to use a foreign lib as a es6 module as context


Perhaps it is trying to pull in react?


@thheller hrm, another user that got derailed by implicit quoted symbols in EDN


hard to see the takeaway other than maybe people should ask more questions


Yeah, reading that article was a little frustrating, seeing _SINGLEQUOTE_ in the error message.


still - we definitely need an error for non-symbol :main


(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


yes it was hard to read, I'm tempted to write up a quick gist to show it working


also wondering if figwheel main catches this error


ClojureScript Namespace 'hello.core was not found on the classpath.


not the best


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.“)


its really good feedback


yes, I think that post has way less to do w/ :npm-deps than low hanging fruit




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.


anyways I don’t think that post should be used as :npm-deps doesn’t work


the story is broader than that


(symbol? (read-string "'asdf")) => true


should have fixed this a while ago


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


it mirrors a lot of my experience as well


a significant amount of feedback about :npm-deps at this point is not super helpful since nearly everything anyone might encounter is already known


so I don’t really know if there’s any news here


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


I can sympathize with lack of contributors being a problem, certainly


ha not looking for sympathy 🙂


just reiterating that nothing is going to change any quicker unless people work on it

👌 4
👍 4
Alex Miller (Clojure team)20:06:34

Features = Minds * Action

Alex Miller (Clojure team)20:06:09

I totally just made that up


It is by will alone I set my mind in motion.


Actually, that sounds like me, before my morning coffee.


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)


no but it’s not hard to understand


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


@lee.justin.m if you’re really curious asking questions in #cljs-dev is probably best


@dnolen thanks. i just thought i would read up if something existed. i’ll read some source before i bother you guys in #cljs-dev