This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-08
Channels
- # aleph (11)
- # arachne (7)
- # aws (1)
- # bangalore-clj (4)
- # beginners (24)
- # boot (128)
- # bristol-clojurians (23)
- # cider (1)
- # cljs-dev (43)
- # cljsrn (6)
- # clojure (178)
- # clojure-austin (3)
- # clojure-chicago (1)
- # clojure-dusseldorf (14)
- # clojure-finland (15)
- # clojure-france (6)
- # clojure-italy (18)
- # clojure-portugal (2)
- # clojure-russia (67)
- # clojure-spec (148)
- # clojure-uk (55)
- # clojurescript (199)
- # core-async (4)
- # cursive (18)
- # datascript (5)
- # datomic (120)
- # devcards (3)
- # dirac (53)
- # emacs (11)
- # events (3)
- # gsoc (7)
- # jobs (1)
- # lein-figwheel (25)
- # leiningen (5)
- # lumo (12)
- # off-topic (29)
- # om (174)
- # om-next (2)
- # onyx (7)
- # perun (10)
- # protorepl (6)
- # re-frame (12)
- # remote-jobs (1)
- # ring (19)
- # ring-swagger (25)
- # rum (6)
- # spacemacs (13)
- # sql (3)
- # untangled (88)
- # yada (7)
according to this: https://groups.google.com/forum/#!topic/clojurescript/7wAO_GzsITM it's goog.DEBUG
There was a fairly short post about effectively using goog.DEBUG somewhere. Wish I could find it now. Perhaps something for the clojurescript website.
Hi, is there a way to DRY this up?
(ns myns
(:require [foo.bar.baz.one :as one]
[foo.bar.baz.two :as two]
[foo.bar.baz.three :as three]))
@pbaille there is but I wouldn't recommend it
and neither does stuart sierra: https://stuartsierra.com/2016/clojure-how-to-ns.html#prefix-lists
my main reason is that you want to be able to grep for foo.bar.baz.one
and find all places where you use the ns
oh I didn't know that @thheller
@ashnur I don't know what makes you compare this (fancy) syntax to an action movie, but I think despite the fact that it is arguably complex, I find it quite clear. Easier that the destructuring syntax for instance.
@pbaille my point is that i know lots of things that look good but i wouldn't do them myself
"looks good" is not an argument in favor of one particular way of writing code over the other
now, you said that you "find it clear" which is a very different notion, and i would say that it depends on your education and what you are used to, and it's not some inherent property of that particular way of writing code
i have a colleague who is often arguing that he finds i++
way simpler to understand than i+=1
because in the latter there are 3 things to understand, which variable, what's happening to it and what is the value passed, while in the first case there are only two things to notice, which variable and what's happening to it. I can't agree with him, I think all this is just about what someone is accustomed to.
Hey! Weβre using transit/writer
to encode certain javascript types (js/BigNumber) as "arbitrary precision decimalβ (the βfβ tag). Can we do the same with EDN using BigDecimals? Eg {:val (js/BigNumber. 3.1)}
-> {:val 3.1M}
@grav not if you want 3.1M
, you can however print BigDecimal
using a custom tag and read that as such #my/bigdec "3.1"
or so
in CLJS the print would go IPrintWithWriter
protocol, just extend-type
that onto BigNumber
But we might stick with it, if itβs too hacky. Though custom tags sounds like a good solution
people say that jvm is fast and everything, but the whole stuff is still too heavy and sluggish. i never know if i am waiting for my browser to run my code or me and my browser both waiting for the jvm to compile it
i end up wasting lots of time refreshing and resaving just because nothing happens for way too long and i am unsure if it will
it should be live-reloading your code for you
have you watched bruceβs talks? does what youβre seeing match his demo?
you shouldnβt need to refresh, then, which is what you said you were doing.
so maybe donβt have it do that until youβre happy it works?
sounds like this is a complaint that βeverything is slowβ, which the only real answer is βsorry to hear thatβ. specific issues can receive better assistance π
i am sure i could rewrite to not have to do that, but i have not yet thought about how. that said, it shouldn't be slow at load, that's not a defense for slowness, that i shouldn't do it π
thereβs what is, and thereβs what we think should be. i find dealing with what βisβ leads to happier results sooner
that's actually something i can agree with, although I admit, i am an idealist. i don't like the real world stopping me doing what i like π
it could be that youβre reloading too much code because of how your namespace dependencies are set up. browser reloads involve a lot of network, which is always going to cost time
you and me both, buddy
Aaaaanyway, if anyone has time to look at it and give me feedback what i should fix https://github.com/ashnur/cljs-combo-network
@ashnur I also struggled with figwheel reload times, these options helped in my situation:
:cljsbuild {:builds [{:id "dev"
:compiler {
:recompile-dependents false ; this makes hot reloads noticably faster. but in very rare cases can cause stale code bugs?
:parallel-build true ; mostly speeds up initial compilation
....
@metametadata thanks
so i suggest you untangle your code from onload and set it up to run via figwheelβs reload fn instead
and follow bruceβs great advice for reloadable apps (so keeping state stable during reloads)
if you separate concerns like this, you almost always write simpler, faster code
this is generic advice though, and may not help you at all pinch-of-salt.gif
you are talking about stuff i know nothing about, can i ask you to please don't just say names but give links or keywords that are easy to google?
https://github.com/bhauman/lein-figwheel#configure-your-builds > :on-jsload
i hope this helps you ashnur π i understand this kind of frustration and actively work to eliminate it from my own life
almost always a common problem with a well understood fix
yeah, that thing about frustration, i hoped that clojure will be different and it's actually worse
ah, so youβre new to clj/s?
also remember that a reloading workflow, when set up, gives you a lot of leverage
then watching a couple talks and actively applying what you see will give you a tremendous boost π
robert-stuttaford: i don't think there is any cljs talk that could help me and i have not yet seen it. same goes for the one you linked. I will re-watch it of course because just because I saw it already doesn't mean I remember anything, but I definitely saw most of the relevant talks
i follow the scene mostly because i realized very early that this is where the ideas are seeping into the mainstream frontend development
well, good luck.
but i would like to be able to force someone who is saying fast to sit down at my machine and make it "fast" in like 10 minutes and then i hook up my js environment and show what is the difference. jvm enthusiasts are blind to the reality imho :))
well, what do you consider new? i used mori/datascript for more than a year now actively in javascript projects, and most of the core ideas are not new
@ashnur CLJS recompilation is pretty much instant, for me ~500ms when compiling a few files. And the browser loads them in another 200ms or less. So very very quick. Are you sure you aren't doing expensive computation when your browser exectues/loads the JS files?
because suddenly something that would take you a minute to verify now only take you 5 seconds
the tooling though... well i am new to that because i never liked java/jvm and i never will π
the Dream exists. many of us live it. you just have to soldier through the bootstrap phase
i think most people who say that just figured that easier to not have to do the things that make you deal with the hard stuff
so the upfront cost is (IMO) offset by the long-term payoff in confidence and velocity
Not sure how expensive this one is: (def G (ggen/erdos-renyi 20 0.10))
but maybe defonce
it if you can.
when this is done, i want a UI for selecting which random graph generator algorithm i want to use
@ashnur "looks good" meant that I can't see any problems/downsides to this syntax, but I agree that I should be more explicit! the grep argument is not suffisant in my opinion. who is relying on grep to analyse a clojure project? (that's not rethorical) in clojure the code parsing should be always structural no? (not string based, but expression based). For me this syntax remove noise for not so much of a cognitive overhead. but as you mention it is a matter of education and taste.
the grep argument is a belief in the power of text (http://flylib.com/books/en/1.315.1.30/1/)
at least in the absence of better static analysis tools, grepping is very powerful
it also helps people new to the code find their way around
it's not a knock-down argument but I think it's a pretty good reason not to needlessly impair greppability
yes I agree that grep is a powerful tool but for clojure source parsing it does not make much sense I think. But I see your point and agree with it. Thank you for the link I will read it.
it seems to me that i should not just wrap almost everything into that function, but that i should write a whole lot of other stuff that goes around and resets values in the DOM
seems like a waste of time, considering that i can just hit CTRL+R now and the same thing happens by itself.
if i just had a simple state -> view system as i like normally to have, then it would be enough to reset the state
@ashnur As an example, I build on re-frame/reagent. I use :on-jsload to trigger a fresh render so that if view fns have updated the UI reflects them. Also, if I have "page transition" behaviour in my single-page webapp then I might retrigger that too... that's useful or not since it resets some app state. Depends on my need.
that sounds as i imagined it. the thing i am building now is mostly just about what's on a <canvas>, and that part i render out with d3
Sounds like it might be useful then.
Again, as an example, my page refresh is fairly heavy since there's 22k lines of code and a heap of features. Figwheel pushing updates is super fast by comparison. Caveat being that when I change a core lib which many files rely on the refresh slow as most files are reloaded.
And while I'm singing Figwheel's praises there's also the wonder of keeping your app-state so that you can make incremental code changes to a specific feature. That can avoid the issue of having to click a bunch of buttons to recreate a specific scenario after refresh.
question about closure-compiler JS libs and exports: we have a clojurescript project which pulls in a closure-compiler compatible JS project via the :libs
compiler flag. However, the @export
s in the JS project don't get exported into the resulting minified JS. We're using another non-closure-compiler, third party JS which expects the symbols from the closure-compiler-compatible JS project to be available, but they aren't, because they're minified. Is there any way to fix this?
@tstephens do you mean @export
?
@tstephens it should work, if it doesnβt work you should be able to reproduce without ClojureScript
as in, create a JS project, pull in another one, and see if the inner projects @export
ed symbols are in the output?
@dnolen still working on reproducing it with a JS project, but the docs here (https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export-export-sometype) say that the closure compiler needs to be executed with βgenerate_exports
to get the JSDoc @export
annotations to be included, and I donβt see any way to enable that option via the clojurescript compiler?
@tstephens we might be missing it, file a JIRA ticket
@tstephens in the mean time youβll have to work around it via goog.exportSymbol
then
if someone has a bit of time, i would really appreciate some input, i tried to work into the code what people already told me
@dnolen created ticket http://dev.clojure.org/jira/browse/CLJS-1931 for the βgenerate_exports
issue. thanks for your help
@tstephens thanks for the report!
if no time for that, it would help to know how can i reduce the size of the question so people have time to look at it
@ashnur a really helpful way to reduce a problem/question is to create a minimum reproducible example. Especially when talking about project configuration, starting from a clean-slate and having the absolute fewest lines of code to demonstrate an issue makes it way more enticing to look at
so I would expect a minimal example to be just setting up a basic figwheel config that has :on-jsload
just log to the console
maybe i am not clear enough. my issue is not that on-jsload doesn't work. my issue is exactly that i don't know how to make it work for me in this situation where i am drawing to canvas with d3
@ashnur one thing that may be problematic is you have this on the top level:
(def init-node (rand-int (aget (aget Gjs "nodes") "length")))
(def messages (js/Array))
(.push messages init-node)
, and then you also have some mutations in the lifecycle methods. Probably better to just do that stuff in the lifecycle methods also. (Not sure if that is the problem, though)@ashnur it looks like you are trying to learn too many things at once: cljs itself, figwheel, reagent
@ashnur replace the body of on-js-reload
with (reagent/force-update-all)
and that will work
@thheller i think that you are mistakingly thinking that i use js methods because i don't know the cljs solutions
similarly, reagent/react is very straightforward in itself as an idea, although I admit, learning a lot of new terminology is really hard, when people don't even know what i am asking about
well, i mentioned before that after finishing i hope i will be able to find solutions that are more idiomatic to cljs
@isak i think i understand now. took me a bit of time to pull the code and launch everything
i am really curious btw if it's possible to not use "globals" and reach similar performance, because even in the js version i wished i could've done that but eventually had to give up and just use variables from shared scope
@jr thanks, it really works, now i have to go and read about it to find out why it works π
(defn ui-control
[state]
[:div {:class "Control__ui"}
[:button {:on-click #(reset! state state)} "restart"]])
the globals you are defining in the namespace will be re-evaluated (unless marked defonce)
the whole state thing is not used now. my original idea didn't work out and decided to just port everything first and then fix things one by one
@jr yeah, so to fix this, i have to use those reagent lifecycle methods @isak mentioned, right?
no you call force-reload-all
. the reagent components will only automatically re-render if one of their dependent reactive atoms has changed
ok, so if i want to re-render on-jsload then i should change some atom in :on-jsload that is tied to reagent
@thheller btw, i was never able to learn from easy examples. if I don't see how things work in the edge case scenarios, i simply confuse everything with everything. I knew that trying to do shared mutable state in cljs is not going to be easy, but that's exactly why i chose this as a learning project π. If I can do this, I am not going to be afraid of trying something that's less... ugly π