This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-03
Channels
- # aws (1)
- # bangalore-clj (3)
- # beginners (3)
- # boot (9)
- # business (1)
- # cljs-dev (72)
- # cljsjs (7)
- # clojure (86)
- # clojure-austin (1)
- # clojure-belgium (4)
- # clojure-brasil (14)
- # clojure-conj (3)
- # clojure-dev (10)
- # clojure-italy (4)
- # clojure-poland (14)
- # clojure-russia (36)
- # clojure-spec (144)
- # clojure-uk (50)
- # clojurebridge (1)
- # clojurescript (160)
- # clr (2)
- # core-async (8)
- # cursive (56)
- # datomic (34)
- # devcards (3)
- # emacs (2)
- # ethereum (1)
- # events (3)
- # hoplon (21)
- # jobs (2)
- # leiningen (9)
- # luminus (3)
- # off-topic (1)
- # om (26)
- # onyx (42)
- # pedestal (29)
- # protorepl (1)
- # re-frame (43)
- # reagent (26)
- # rethinkdb (4)
- # ring-swagger (4)
- # spacemacs (5)
- # specter (4)
- # untangled (102)
- # vim (43)
- # yada (10)
@dnolen the gzip size of final app.js is coming to 380K. Is this an expected number?
@rnandan273 it doesn’t seem problematic, you appear to have a lot of dependencies. You haven’t said how much code you have or anything like that.
@rnandan273: that seems like a relatively normal size
Try advanced compilation and eliding asserts
I’m looking for a very simple tutorial for Reagent and re-frame. I have found a game, but I’m looking for something even simpler like a page with a button and an input field to start with. I found this: http://lambdax.io/blog/posts/2016-01-19-snake-game-part-1.html
https://github.com/Day8/re-frame/blob/master/examples/simple/src/simpleexample/core.cljs
@andre Thanks
What's the best practice way of handling namespaced keys when transforming with clj->js
and js->clj
, as the namespace part of keys are dropped?
For example
(js->clj (clj->js {:post/id 1 :post/title “Breakfast"})) => {“id" 1 “title" "Breakfast"}
Is there a way to keep symmetry between these two transformations, without losing the namespace part?
@dnolen Good ide, will add that channel!
@dnolen Okay, thanks. Do you know the reasoning behind using a destructive transformation? It seems to me that this is quite a large problem, especially when the adoption of clojure.spec
and the best practice of namespacing keywords is increasing
clj->js
is js->clj
are also helpers for beginners and were added with great regret to the API
also if you’re doing interop with JS apis, namespaced keys aren't useful - since that’s not idiomatic for JS
http://stateofjs.com/2016/introduction/ clojurescript mentioned in here.
@gerred thanks for sharing that! though it more or less reinforces my long standing beilef that JavaScript users either don’t know or care about compile to JS solutions which are not JS->JS or very close (TypeScript)
of course! it was very interesting to read as someone on the other side - I waxed on it a bit in the reagent room, but I’m coming back over from Elm to ClojureScript.
the numbers on “tried it, wouldn’t use it again” on clojurescript are interesting. not quite coffeescript, but its a higher number.
@dnolen Coming from js, it took me a long time to realise that cljs wasn't JS->JS. It confused me until I learned Clojure.
i wonder how that breaks down on length of time using it, what version they used it, etc.
@gerred yes but we’re a rounding error in that survey - so those numbers don’t mean anything
@gerred I am curious to hear experience reports from someone coming back from Elm - they’re doing a great job these days attracting users
but typical Elm users aren’t typical ClojureScript users - ClojureScript users are generally just Clojure users doing full stack
yeah. I’m not doing Clojure at all, if I were it’d be via clojurescript + node, but I use Elixir or Go these days. that said, I’m interested in checking out luminus now.
so re: Elm and coming back, I think we’re just in this static typing swing that makes ML attractive. in a large app, though, I feel like I was breaking flow constantly (as opposed to using figwheel). its still an edit -> compile -> debug -> run -> parse type errors -> edit cycle.
clojurescript feels much more like prose that I can flow and change and enjoy programming with. ML-like languages are nice, sure, since you have to design all the types up front, but now you just get notifications when something breaks.
when you do a refactor, for example, and for me it breaks anything I’m doing to sit and parse out type systems.
much faster for me to run -> something breaks -> read error -> fix -> push in small isolated changes rather than compiling and clenching.
@dnolen for that 65% number, I wonder how many clojure users do frontend work but don’t use clojurescript, vs how many just don’t do frontend work at all
@gerred i think it's a matter of confidence. Elm types give you a high confidence that if it compiles, it'll work as intended, and that during a refactor you covered all cases
it also just didn’t grow for me. i built a fairly large app and whereas I had a lot of refactoring confidence, it was all a lot slower for me.
I tend to disagree it matters much for UI work though - correct is all about state transitions
oh, sure, hadn’t thought of it like that. you can’t do that with Elm though. doThing : User -> User doesn’t encode much unfortunately, and ML types don’t create type safe state transitions, that’s where the hard bugs lie.
@dnolen i sorta agree, but if someone goes and changes an om-next key your app breaks and you wouldn't know better
(i think that types do make sense in a elm alike architecture, and much less sense in a om-next alike architecture btw)
so I really like the whole premise of using spec and contracts to create runtime checks.
@dzannotti yes if you don’t have tests, or devcards, or any other thing to catch stuff like that
its one thing I’ve always really liked about erlang/elixir is the opt-in type system, and I started hearing about it more with clojure/spec and discovered racket contracts.
i don’t fully understand spec/contracts yet as opposed to dialyzer types, so I’m not sure what the limits are there.
I for one find that I care less about capturing mistakes at compile time if you have a fast feedback loop
I think types are great or an massive hinderance, depends on the system architecture
so beginner question. will clojure.spec replace core.typed? or rather, what’s core.typed place vs. spec’s place?
i also think the industry is in a static typing swing at the moment as a reaction to fatigue in other places.
the growth of typescript (flow to some extent as well) is pretty huge. maybe this is more survivorship bias to large web apps since I work on those.
as compared to everything else. hell, I think a lot of people are using Go, but when you look at the whole industry that’s not true.
I wonder if they are, because they don't know any better/are not interested to know better
it’s what you learn at school, it’s what people hire for, it’s what all the books cover
i once upon a time worked at Rally (a datomic customer) before they got acquired. we were able to sneak in Clojure because it ran on the JVM. Go was a much harder sell beyond the platform team.
in the end that’s why I think Clojure(Script) strategy is the only sustainable one for a Lisp in the modern world
i’ll be interested here in 5 years to see the links between the C++, Rust, and ML-like communities. i predict that’ll be a heavy area of cross-pollination.
i like Racket and various CLs a lot but I wouldn’t put them in any place that I worked.
whereas Clojure I can absolutely walk in and dump somewhere, probably a lot easier than Go in a lot of places.
probably it's because i'm not a clojure god - but i often struggle to understand other people's clojure, while i know perfectly well mines and i wouldn't trade it with Java/JS for the world (i wonder if that's a contributing factor for others)
@dzannotti you can get carried away with brevity with Clojure - the downside to its FP roots
hopefully having spec included in the language will help with readability/maintainability 🙂
@jrheard probably won’t prevent code-golfing - but at least you know what the inputs and outputs should be - and that’s great
yeah, if i know that k
is a ::foo/bar and i can see the definition of that somewhere, i’m happier than i was before
is it possible to instantiate a record without knowing its type ahead of time, like so? (defn new-record [Type] (Type.))
i’ve played around with various syntax quotings with no luck.
(not sure if this is specifically a cljs Q but that’s what I’m working with.)
cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (defn instantiate-x [x] (new x))
#'cljs.user/instantiate-x
cljs.user=> (instantiate-x Foo)
#cljs.user.Foo{}
@joshfrench it’s not, long outstanding bug actually
@anmonteiro technically I think that may not be allowed 🙂
I had no idea, I think I’ve used it before 🙂
right, so what are you saying we should fix?
IMO platform quirks like this should be allowed. just like specify!
exists and can’t in Clojure
ah, gotcha
so it seems that the problem is that it works
but we should restrict it for some cases?
maybe worth taking this to #cljs-dev
@anmonteiro sorry that ticket is just wrong - it should always work 🙂
sorry I still don’t understand. isn’t it explicit by the ticket that it all works?
what is the half that doesn’t?
(new x)
sems to work for my admittedly trivial use case, fwiw. i’ll keep in mind that it may not in other circumstances. thanks!
@anmonteiro I would look in JIRA a bit more - there may be some cases I closed around this
@dnolen I’ll keep looking, but these work in Planck & noderepljs
:
cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (def x Foo)
#'cljs.user/x
cljs.user=> (new x)
#cljs.user.Foo{}
cljs.user=> (let [x Foo] (x.))
#cljs.user.Foo{}
nothing to apologize for, thanks for digging
oh I get it:
cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (def x {:foo Foo})
#'cljs.user/x
cljs.user=> (:foo x)
cljs.user/Foo
cljs.user=> (new (:foo x))
⬆
First arg to new must be a symbol at line 1
is there an actual ticket for this ^ though?
CLJS-693 should probably be closed or change its description, right?
hey all I spent sometime this weekend putting together a clojurescript library to retrieve maven dependencies ala Aether + Pomergranate https://github.com/eginez/huckleberry
at some point @shaunlebron and I talked about creating less jvm-centric tools