This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-24
Channels
- # announcements (1)
- # aws (140)
- # beginners (41)
- # calva (47)
- # cider (43)
- # clj-kondo (36)
- # clojure (178)
- # clojure-europe (12)
- # clojure-gamedev (2)
- # clojure-italy (1)
- # clojure-nl (17)
- # clojure-russia (3)
- # clojure-spec (37)
- # clojure-uk (97)
- # clojurescript (173)
- # core-async (16)
- # cursive (18)
- # data-science (2)
- # datascript (6)
- # datomic (32)
- # dirac (16)
- # duct (16)
- # events (2)
- # figwheel-main (7)
- # fulcro (8)
- # graalvm (18)
- # immutant (3)
- # joker (2)
- # kaocha (8)
- # nrepl (6)
- # nyc (2)
- # off-topic (62)
- # quil (3)
- # re-frame (18)
- # reitit (6)
- # ring-swagger (1)
- # shadow-cljs (119)
- # spacemacs (4)
- # specter (2)
- # tools-deps (10)
- # vim (58)
- # xtdb (9)
Sorry for copy the topic, but this group is more active. Anybody know this issue? I have this first time with figwheel-main https://clojurians.slack.com/archives/CALJ3BFLP/p1571930616030100
I was trying with npx webpack --mode=production
and npx webpack --mode=development
- both work during figwheel developing
@kwladyka that looks like an externs issue. try enabling :infer-externs
. you can debug this a little by setting :pseudo-names true
in your build config. that'll still error out but it'll make the "problem" easier to find
that is completely expected and a side effect of the :advanced
optimizations we want to have in CLJS
hmm, what is going under the hood? I mean :advanced doesn’t detect dependencies or is it my bug?
yeah. I think the externs you are missing are for props
though. there was an open issue about that
the code is telling you the it tried acessing $argv$
on something that was undefined
in this case I believe it is this.props.argv
which is getting renamed to thing.$props$.$argv$
with pseudo-names
hmm but breakpoint is to set on specific line of file. How can I achieve discovering reagent?
function $reagent$impl$component$props_argv$$($JSCompiler_temp_const$jscomp$115_c$jscomp$223$$,$JSCompiler_temp$jscomp$114_p$jscomp$69$$){var $JSCompiler_temp_const$jscomp$116_temp__5737__auto__$jscomp$7$$=$JSCompiler_temp$jscomp$114_p$jscomp$69$$.$argv$;if(null==$JSCompiler_temp_const$jscomp$116_temp__5737__auto__$jscomp$7$$){$JSCompiler_temp_const$jscomp$116_temp__5737__auto__$jscomp$7$$=$cljs$core$PersistentVector$EMPTY_NODE$$;$JSCompiler_temp_const$jscomp$115_c$jscomp$223$$=$JSCompiler_temp_const$jscomp$115_c$jscomp$223$$.constructor;
but it is very not obviously and it is not even breakpoint. Is it you what you mean?
sounds like this one. Still very not obviously for me. I mean for me it could mean everything what reagent try to load. But yeah, good you know and can share with me 🙂
Also, there are a ton of references out there to using phantomjs based ones - which is an unsupported, dying project
then there is karma+chrome /etc. which requires some node setup. that can work, but requires cooperation from the infrastructure - like travis
the annual clojure survey had a question about what people are using in cljs, in case those results are helpful
background is just trying to get clara-rules
cljs-side a bit more up-to-date. it’s using phantom and facing troubles there
I'm just glad "not running tests" isn't the highest anymore :)
the open ended comments are useful here too
and I would welcome feedback about what the available options should be in this question for 2020
can you scroll that pane?
> Move code to cljc and test Clojure part - Getting testing to work for cljs is not a pleasant experience. this one speaks to me - I’ve done this a good deal hah (obviously not testing dom-side)
koacha is making a name for itself in the 64 comments though - interesting to explore
with shadow-cljs, I can’t use lein-doo or cljs-test-runner because shadow-cljs does a lot to add on top of the CLJS compiler that my application needs
I was trying out lein-doo
but pretty annoyed with some of it’s opaque issues - that have several github issues linked to it, but no details and I don’t think it is really actively maintained (at least it seems)
so if I’m going to move away from phantomjs issues, I don’t really want to move to another unmaintained thing
In my specific case of clara-rules
, don’t really care about DOM-like things anyways. It’s just a non-visual lib that can be used in JS. So just want to test it compiling and working in that way. So a bit nicer. I’m not trying to get carried away here and tests layout stuff etc
it has a :karma
target that makes this pretty easy. but I don’t think this actually does a whole lot other than look for tests, spit them in a file and a simple runner ns
you might consider testing in node? if you think that gives you the confidence you want from your CI process
there’s a node-test
build in shadow-cljs as well: https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-test
I'll just generally hand-wave around this and suggest cljs testing might be an area for clojurists together to help in
Agreed, we'd love to get an application from anyone working on a ClojureScript testing project.
also, there was a discussion the other day about web session handling ala buddy/friend and that area that sounded like it would be a great area to fund
@U07QKGF9P would be cool to have someone with a real security background look at buddy properly perhaps 🙂 (thinking particularly on the crypto).
I'd like to but there's a few problems there: 1. I'm on the board now and I'm the president of our new legal entity so there's a direct/obvious COI meaning CT can't fund me 2. Haha sure I'll go do that in my copious spare time even if you fund me 3. It's hard to say negative things about projects even though that's kind of what my job would be (I've looked at Buddy before, I have strong opinions on API design for security products (having been at the cradle of pyca/cryptography), so, uh, you know, it'd be lively :))
FWIW the "design" for this in shadow-cljs separates out the compilation from the actual running of the tests
node is a whole lot easier since you just run node the-test.js
and don't need to setup an entire headless browser and so on
we get this error: Uncaught TypeError: http://SortableHOC.Sl is not a constructor while we didn't get that one with Java 8
looking at the code the error isn't weird. it's maybe weirder that it used to work in Java 8 😉
I did an update of my library https://github.com/kwladyka/form-validator-cljs to validate form in cljs using spec
and fn
. I added a demo with example of code https://kwladyka.github.io/form-validator-cljs/
Now it is easier to see what library can do, but it has more use cases.
What do you think about the library and the demo? Is it understandable? Is it useful for you?
Yeah, really wanted to get this feedback if somebody will use it. Library exist a long time and I don’t even have idea if people really use it. Considering stats it is not popular 🙂
So thinking if library is not so needed or it is only about popularity and “advertisement”
@kwladyka There are multiple ways to promote your library if you want to do that. Putting it in announcements is one thing, but you can blog about it, why it's great. You can post on Clojureverse to showcase your project. Also on Reddit.
Also, definitely consider adding topics: https://help.github.com/en/github/administering-a-repository/classifying-your-repository-with-topics#adding-topics-to-your-repository
Heh and here is a point. I don’t even have an idea how to use Reddit. It is not popular in my country. First time I hear about https://clojureverse.org/ But thanks, I will learn this things
Is there an alternative to requiring-resolve in ClojureScript? Otherwise I have to create a whole other namespace for 1 function which uses a library conditionally.
I suppose in ClojureScript you pay the bulk of all your libraries anyway (until compilation), so there a top-level require would do the job?
oh, but it would need to be in a macro to be conditional on the namespace existing, boo
in JS all IO is async. so loading the namespace would require a callback before it can continue
also conditions around require would probably make advanced compilation and analysis much more tricky?
the closure compiler doesn't support this at all too. that would be another reason yes
Maybe this is just for my case, but I would assume that all branches are accessible (except where google closure can assume otherwise)
I should probably try and understand a little better: how does clojurescript determine the dependencies? Doesn't it analyze the whole file? Couldn't all requiring-resolve
be appended to the list of namespaces to goog.require?
I understand the general context of where I'm getting to if I want a semantic match. But the behavior I'm really looking for is:
- If ns is known, then add to goog.require for the file, and call resolve
on the sym.
- if ns is unknown, do nothing unless function is called then blow up
so if you think about this as just getting an extra goog.require
in there you are looking at the wrong thing
the problem is that all dependencies have to be loaded before the actual file is loaded because of the async IO
All dependencies have to be loaded before the js, but not the cljs, no? I must not be understanding
I'm not really trying to prevent loading. I'm trying to make it so require didn't blow up.
What is the situation in which the namespace exists in some cases, but not in others? Different ClojureScript compilation runs with different environment variable settings (or similar), but at least some common source files in both compilation runs?
My question was directed towards dominicm -- sorry if that wasn't clear
So perhaps one way to achieve the goal is to have two source files foo1.clj and foo2.clj, where foo1.clj is compiled if the dependency is present, and calls the real function, and foo2.clj is compiled if the dependency is not present, and throws an exception if its function (with the same name) is ever called? Sounds a bit clunky, but possible.
So, just so I'm entirely clear, I'm not after deferred loading here. I understand the limitations there. What I'm thinking of is another lie. A static requiring-resolve that that does the same thing as require. But if it didn't find the namespace it would replace requiring resolve with something that would blow up at runtime. Otherwise, it replaces it with whatever resolve does right now.
(def my-magic-function (atom nil))
(defn call-the-thing [a b c] (@my-magic-function a b c)
Is there a run-time cljs way to check whether a specific namespace exists?
I guess. Is there an inside-cljs way at compile time to detect whether a namespace exists?
if you don't have an explicit require for something it is not guaranteed to exist before the ns checking it is compiled
Right, so seems like catch-22 for an inside-cljs-language solution to the desire. Only alternative I can see is something in the compile/build infrastructure that does it.
(the previous comment is assuming that the optional dependency's source code is not under dominicm's control or ability to modify -- thheller your suggestion about the atom seems to work if the optional dependency's source code is under dominicm's control)
I think domincm is dancing around the idea of a macro or reader thing that looks at the classpath, sees if a particular namespace exists, then emits some code. but I don’t know if the compiler/analyzer lifecycle works like that
the only way to affect what ends up in a build is via build config and :require
in the actual sources
@thheller this is roughly what I was getting at
(defmacro require-resolves
[body]
(let [to-require
(set
(map #(namespace (second (second %)))
(filter #(and (seqable? %) (= 'requiring-resolve (first %)))
(tree-seq seqable? seq body))))]
(if (every? #(io/resource
(str (-> %
(string/replace "-" "_")
(string/replace "." java.io.File/separator))
".cljs"))
to-require)
`(do ~@(map #(list 'require (list 'quote (symbol %))) to-require)
~(walk/postwalk
(fn [x]
(if (and (seqable? x)
(= 'requiring-resolve (first x)))
(list 'resolve (second x))
x))
body))
(walk/postwalk
(fn [x]
(if (and (seqable? x)
(= 'requiring-resolve (first x)))
`(throw (ex-info (str "Unable to find " (first x)) {}))
x))
body))))
(require-resolves
(defn foo
[]
(let [x (requiring-resolve 'cljs.core/foo)]
(x))))
obviously the detection of existence wouldn't just be doing io/resource on the file, I'm assuming there's some compiler internal for that.
Agreed, we'd love to get an application from anyone working on a ClojureScript testing project.