Fork me on GitHub
#clojurescript
<
2018-06-13
>
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.

juhoteperi07:06:59

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

juhoteperi07:06:02

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

giovaferra07:06:34

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)]
       (try
         ~@(map bind-value binds)
         ~@body
         (finally
           ~@(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!

metametadata12:06:46

@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/

scknkkrer13:06:08

Thank you so much.

darwin13:06:33

@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] https://github.com/binaryage/cljs-zones

darwin14:06:02

btw. if you are targeting recent nodejs, you could also look into https://nodejs.org/api/async_hooks.html

darwin14:06:39

this is basically nodejs-specific-api for implementing something like zone.js (effectively)

giovaferra15:06:31

@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 😞 ).

mikerod15:06:37

@bhauman I hadn’t heard reports of it working out well still at this point, so didn’t include that in the list.

mikerod15:06:10

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

pesterhazy15:06:36

Just ran into a case where requiring node modules via ns requires broke when switching branches

mikerod15:06:40

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

pesterhazy15:06:59

It still has rough edges for sure

bhauman15:06:26

what do you mean? switching git branches?

bhauman15:06:58

but you have been using :npm-deps otherwise?

pesterhazy15:06:25

Yes switching git branches in the project. The error reported was this: https://github.com/bhauman/lein-figwheel/issues/576 @bhauman

scknkkrer15:06:49
replied to a thread:

But I couldn’t find any official documentation about this functionality.

pesterhazy15:06:07

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

bhauman15:06:54

and foreign-libs

pesterhazy15:06:51

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

pesterhazy15:06:53

my understanding of the new js import feature of the cljs compiler is imperfect, so I might be using them wrong

bhauman16:06:03

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.

bhauman16:06:43

It would be really nice if we could rely on it

richiardiandrea16:06:42

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.

folcon16:06:29

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

thheller16:06:40

FWIW :npm-deps in 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)

😱 4
tungsten16:06:47

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?

tungsten16:06:45

Anyone have any idea what this error means:

tungsten16:06:54

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

tungsten16:06:25

Perhaps it is trying to pull in react?

dnolen16:06:36

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

dnolen17:06:46

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

mfikes17:06:17

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

dnolen17:06:16

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

mfikes17:06:27

(Frustrating in the sense of seeing so much copy written, without being able to suggest, please remove the ' from your config.)

dnolen17:06:19

yeah the author obviously went through the Quick Start and then got caught on a trivial error - albeit an annoyingly common one

bhauman17:06:40

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

bhauman17:06:00

also wondering if figwheel main catches this error

bhauman17:06:32

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

bhauman17:06:37

not the best

justinlee17:06:20

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

bhauman17:06:50

its really good feedback

dnolen17:06:11

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

bhauman17:06:20

absolutely

thheller17:06:58

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

dnolen17:06:18

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

dnolen17:06:27

the story is broader than that

bhauman17:06:05

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

bhauman18:06:03

should have fixed this a while ago

lilactown20:06:03

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

lilactown20:06:01

it mirrors a lot of my experience as well

dnolen20:06:42

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

dnolen20:06:02

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

dnolen20:06:19

at the same time people continue to complain about stuff they aren’t contributing too 🙂

dnolen20:06:49

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

lilactown20:06:04

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

dnolen20:06:18

ha not looking for sympathy 🙂

dnolen20:06:14

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

mfikes21:06:56

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

manutter5121:06:10

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

mfikes21:06:35

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)

justinlee22:06:07

is there a walkthrough of what :npm-deps internals are doing and/or what the design principles are? (besides the not-an-island article)

dnolen22:06:36

no but it’s not hard to understand

dnolen22:06:29

we resolve the node_modules dependency graph and make sure they are passed as inputs to Closure Compiler along with your own stuff

dnolen22:06:01

welp trying to use Webpack to test something - this ain’t any easier than ClojureScript that’s all I gotta say

dnolen22:06:58

modern JS development seems about as straightforward as wrangling Maven - sans XML and the information seems outdated

dnolen22:06:29

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

justinlee22:06:15

@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