This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-23
Channels
- # beginners (55)
- # boot (37)
- # braid-chat (1)
- # chestnut (3)
- # cider (4)
- # clara (22)
- # cljs-dev (54)
- # cljsrn (3)
- # clojure (114)
- # clojure-italy (12)
- # clojure-losangeles (3)
- # clojure-portugal (1)
- # clojure-russia (1)
- # clojure-spec (30)
- # clojure-uk (67)
- # clojure-ukraine (1)
- # clojurescript (101)
- # core-async (11)
- # cursive (6)
- # data-science (27)
- # datomic (8)
- # figwheel (3)
- # fulcro (59)
- # graphql (2)
- # hoplon (89)
- # jobs (3)
- # jobs-rus (1)
- # leiningen (3)
- # lumo (19)
- # off-topic (9)
- # om (48)
- # pedestal (2)
- # portkey (4)
- # protorepl (19)
- # re-frame (13)
- # reagent (38)
- # remote-jobs (1)
- # ring-swagger (4)
- # spacemacs (10)
- # specter (2)
why can't protocols have a variadic signature?
if i understand the changes in cljs 1.9.660
it appears that tests were added to ensure that the functionality works but also that warnings are thrown when it is used
what's the rationale behind that?
@dnolen i think this is something that you worked on?
@thedavidmeister the rationale is that it was never supported because it doesn’t work in Clojure either
the fact that it worked is an implementation detail
the tests were added to make sure the warning is produced
hmmm, so how do we migrate something like hoplon to the newer version?
if i have (div (div) (div) ...)
there can be a lot of divs in there
actually i have a real world example with arity 97 and it will likely continue to grow
I don’t know anything about Hoplon
how much do you need to know?
(div (div) (div))
= <div><div></div><div></div></div>
I don’t need to know anything at all
I’m merely stating that I don’t understand what you mean because I don’t know anything about Hoplon
it's just an example use case
so that looks like a function call, you can use variadic functions
i'm not saying "migrate hoplon" i'm saying, how do we migrate code like hoplon
ah ok, so the extra info is that it's implementing IFn
for js/Element
so div
is somehow a macro that translates to a HTMLElement
or however it’s called?
(extend-type js/Element
IFn
(-invoke
([this & args] ...
looks something like this pre 1.9.660
is that library code or user code?
not that it matters, I’m just curious
that's in hoplon
so I suggest making that a single arg that takes a collection
i don't think div
is a macro, just a function
and div
can take varargs and pass it as a collection
is that feasible?
might be better for perf too
so you'd have to change (div (div) (div))
to (div [(div) (div)])
?
and actually it supports attributes too
(div :class "foo" (div))
is currently allowed
if I understand correctly how it’s implemented in Hoplon, that’s not what I’m suggesting
oh ok, can you give me an example?
i think i'm missing something >.<
this is what I’m suggesting:
(extend-type js/Element
IFn
(-invoke [this args]
...))
(defn div [& args]
;; call the above with args
)
i'm not 100% sure that works out to equivalent functionality
let me think about it
currently i can do this
(let [el (h/div)
p (h/p)]
(el :class "foo" p)
and get <div class="foo"><p></p></div>
as i understand hoplon div
fn is just a convenience wrapper to create an element that is a div
and then all DOM elements, whether created by hoplon or not, work in "the hoplon way"
I’m happy to look at a concrete minimal example that represents your problem
I shouldn’t be required to learn Hoplon to understand what you’re trying to solve, sorry
well, if i do what you're suggesting
doesn't ^^ break?
I don’t know
i'd have to replace (el :class "foo" p)
with (el {:class "foo"} [p])
right?
if h/div
returns a function, just make that function varargs too?
no, h/div
returns a DOM element
and dom elements are being extended to implement the IFn protocol so they can be called like functions
i think 😛
sorry, i'm not the original author of this, i'm just trying to help get a PR up to use the latest version of cljs
so i'm poking around as i go as well
I don’t have a good answer for that case then
i am trying to give you as much relevant concrete info as i can
we may have to wait for David’s input
@thedavidmeister here’s how Reagent solved it https://github.com/reagent-project/reagent/commit/3cf045dc8264373d93d9c3a7607dc2a349194681
(goog.dom/isElement (h/div))
this is true
btw if you’re implementing a protocol I’m quite certain you should be implementing all its arities
there is no limit to the number of divs you can put in another div though
actually that looks a lot like the current proposal in hoplon to workaround this
but in my own project i already have a div with 97 children in it
actual: #object[Error Error: Invalid arity: 97]
😞
why is it so important that protocols cannot have a variable arity while it's ok for regular functions?
that's some theory that i'm definitely missing
I also don’t know the answer to that question
it might be because of compat with Clojure
oh ok, so something that works in js but not java?
How do you guys compile your reagent/cljs apps
so they aren’t huge
A question about the npm-deps
flag in the compiler options. Is there a way to preprocess libraries with babel?
@max-tweddell use advanced compilation https://clojurescript.org/reference/advanced-compilation
Perhaps this might also help: https://github.com/magomimmo/modern-cljs/blob/master/doc/first-edition/tutorial-07.md
but i’m still getting 500kb files
I hit the wall with npm-deps and react component. Can someone show me how to create Hiccup from :refer [component] in reagent?
This is the package I am trying: https://www.npmjs.com/package/react-editable-json-tree
Is cljs.spec
supposed to be 100% eliminated under advanced optimizations? I’m seeing 20KB footprint in the output
> Is cljs.spec
supposed to be 100% eliminated under advanced optimizations?
Yup. I, personally, do like it that way.
@thheller I don’t really think that’s the case with the current ClosureCompiler, thus I’m not quite sure about it.
Nah, I’m wrong about it, it’s not getting removed… 😞
I’m on cljs 1.9.521
btw
trying to debug an issue where dev-only cljc files (e.g. js/superadmin/out/om/next.cljc
and /js/superadmin/out/cljs/core.cljs
) are attempting to be downloaded at runtime (observable in chrome console) from my advanced-compiled code inside an uberjar. these 404 as expected, since i only include the single advanced compiled js bundle. seems like i have some dev artifact lurking around. any suggestions on what to look for?
i can see hardcoded paths in the compiled js like:
$cljs$core$cst$0kw$0test$$], [$cljs$core$cst$0sym$0om$0next$$, $cljs$core$cst$0sym$0defui$$,
"resources/public/js/superadmin/out/om/next.cljc", 16, new $cljs$core$PersistentArrayMap$$(null, 5, [$cljs$core$cst$0kw$0variadic$$, !0, $cljs$core$cst$0kw$0max_DASH_fixed_DASH_arity$$, 3, $cljs$core$cst$0kw$0method_DASH_params$$, new $cljs$core$PersistentVector$$(null, 1, 5, $cljs$core$PersistentVector$EMPTY_NODE$$, [$cljs$core$list$$($cljs$core$cst$0sym$0_AMPERSAND_form$$, $cljs$core$cst$0sym$0_AMPERSAND_env$$, $cljs$core$cst$0sym$0name$$, $cljs$core$cst$0sym$0forms$$)], null), $cljs$core$cst$0kw$0arglists$$,
does anyone know where the clojurescript compiler implements js*
? I don’t want to use it, just curious what it looks like
@currentoor https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3052
@anmonteiro thanks!
@rauh its about 150kb gzipped