Fork me on GitHub
#clojurescript
<
2015-10-23
>
dnolen00:10:46

this whole declarative co-located query thing ROCKS

dvcrn05:10:08

Little question, I have a piece of clojurescript code that needs to get required with require by another module I have no influence off. To get that working, I used (aset js/exports "core" myModule.core) All good if optimizations is on :simple but if I turn that off and use a :output-dir, the required object is always empty (contains myModule.core on :simple)

dvcrn05:10:02

is there any way I can solve this problem? Or will this never work because the actual file doesn't contain the export, but the file that is getting imported by goog does (on :none)?

thheller08:10:49

@thosmos: It solved the issue I had so it appears to be working. Naming things is hard ... personally I don't like new-callback and it lives in a util namespace so the call is always (util/callback the-fn this 1 2 3) and never just (callback ...). prevents accidental conflicts with locals.

thheller08:10:25

@dnolen the Union stuff looks great .. going to play with it soon

thheller11:10:34

@dvcrn: you are calling cljs code from js? I don't quite follow what you are trying to do but I think you are looking for ^:export?

bensu14:10:51

@thheller: @dvcrn ^:export is useful under :optimizations :advanced, I think the issue is regarding :none, right? I have no relevant experience but using :none to be consumed from another js module loader (e.g., exports.core = MyModule.core) sounds like a bad idea. :none uses goog.base and Google Closure's module system, which has it's set of conventions and processes, which will probably clash with the other module system

bensu14:10:29

@dvcrn: in any case, I encourage you to put a small repo that shows what you are trying to do (including the relevant js tooling) so we can hack on it

razum2um14:10:07

could someone explain what’s happening to lein-figwheel ? I see a big refactoring there https://github.com/bhauman/lein-figwheel/commit/41d7f67db4376b678566dd263459d3d0826c3d12

thheller14:10:58

@bensu you are correct about :advanced. I always start there because I think that is the only way stuff should be consumed when moving out of dev 😉

bensu14:10:15

@thheller: right, ^:export will be useful during deploy but my guess is that the questions comes from @dvcrn wanting to work with :none.

thheller14:10:09

yeah but I'd answer that by how it would work in :advanced and work backwards from there. the answer "should" be the same

thheller14:10:56

but I'm probably to biased towards browser builds ... things may be a little more relaxed in node land

bhauman14:10:21

@razum2um: what would you like to know?

bhauman14:10:31

its a big refactor simple_smile

bhauman14:10:12

figwheel has reached a point where I understand the domain enough to give it a better shape and make it much more extensible.

mbertheau14:10:15

boot build creates a directory target/main.out. Is it needed for production? I was under the impression that only target/main.js is needed.

martinklepsch14:10:56

@mbertheau: if you compile with :advanced you only need one file (unless you use modules)

mbertheau14:10:41

@martinklepsch: so I can throw away the .out directory for production?

mbertheau14:10:13

Why is it creating it in the first place?

mbertheau14:10:21

Or rather, leaving it around?

martinklepsch14:10:36

@mbertheau: it’s where intermediate stuff goes

razum2um15:10:46

@bhauman: ~2 weeks ago I was trying to build a component using autobuild* now trying to update that simple_smile using figwheel-sidecar.components.cljs-autobuild/cljs-autobuild btw, why it’s blocking on start?

bhauman15:10:29

@razum2um: I haven't release 0.5.0 yet I wouldn't use autobuild to build a component

bhauman15:10:45

oh I gotcha

amacdougall15:10:05

Just tried out the figwheel --reagent template in the office Clojure Club last night, and it worked like a charm! Such an impressive quickstart demo.

bhauman15:10:40

@razum2um: it really depends on what you are trying to do

amacdougall15:10:08

swap! the atom, view updates. Audience gasps. Edit code, save the file, view updates. Audience bursts into applause. (Audience response slightly embellished for narrative purposes)

bhauman15:10:51

@razum2um: I haven't written any docs for this stuff and i'm not sure what you mean by cljs-autobuild blocking

bhauman15:10:46

some example code would be very helpful

bensu15:10:47

@amacdougall: yeah, the figwheel template is my preferred starting point. so much fun to start projects with it

bensu15:10:12

(I use the -- --om flag though)

amacdougall15:10:49

BTW, I haven't been keeping up with Om Next, but does anyone have opinions right now on the six-month outlook of Om Next vs Reagent? I've only used Om Classic, and I'm pondering what to use for my next side project... which will be big enough to have real lock-in.

amacdougall15:10:14

Obviously I should and will do my own research! But I'm also curious to know people's opinions.

dnolen15:10:12

@amacdougall: Om Next is shaping up to be something that will be “done” in the next couple of months

dnolen15:10:39

as in there won’t be anything of interest to do after that beyond integration work

dnolen15:10:59

i.e. making some custom client store (DataScript) work

dnolen15:10:11

but that won’t change anything about Om Next, just the integration point

amacdougall15:10:32

Fortunately I work very slowly! I'll keep an eye on it. Thanks for the info, and for all your hard work.

dnolen15:10:03

@amacdougall: I think an area that will require a lot of work which doesn’t have anything to do w/ Om Next as a thing you use

dnolen15:10:30

thanks to the Indexer idea, I think the kind of tooling you could build around Om Next for Chrome DevTools could be pretty mind blowing

dnolen15:10:52

i.e. hover any element see it’s query, auto-refetch, bug, rewind history via interface, fix code, figwheel hotload, done

shaun-mahood15:10:08

Oh man that would be so nice

dnolen15:10:43

yes next level tooling

dnolen15:10:18

only possible if you can hook into something like the indexer

dnolen15:10:42

stuff like if I run this transaction show me all the components that will change.

dnolen15:10:54

all the kinds of the things that are trivial when immutability is at the center of your system.

razum2um15:10:55

@bhauman: yep, thanks a lot, working amazing, a few questions: 1) where do the logs about rebuild happening go now (see only the first build message now) 2) do you think 2 systems is good idea, or you just wanted to simplify setup exposing 1 component instead of 3? btw, what’s the best practice in component to encapsulate several components?

bhauman15:10:11

@razum2um: logs go to figwheel_server.log, the two sytems thing makes repl interaction much much more expedient for now. But if you understand the code in system.clj you can roll your own system but that is really only needed if you want to create components that send messages to the client.

razum2um15:10:14

@bhauman: right, you guessed what I want - send state to the js from the usual repl, evaluate something on jvm serverside and draw it on client (resetting state)

razum2um15:10:46

@bhauman: frankly speaking I did that some time ago by generating a whole cljs file and using standalone figwheel, but this way kinda sucks simple_smile now with components inside one repl it should be way easier

bhauman15:10:06

@razum2um: don't quite have what you are trying to do. sounds like iPython notebook or something

bhauman15:10:26

you drawing charts based on clj code?

bhauman15:10:54

@razum2um: I think what you want is to use figwheel and just use a macro

razum2um15:10:23

@bhauman: quite so - drawing geo objects on map

razum2um16:10:30

@bhauman: btw, what do you think if system.clj functions were accepting not a system, but a component which wraps other components and only if not given - create a system and such component in it - I think this way it’ll be more clear and idiomatic to incorporate this into application system btw component-lib started with the idea - storing state in private var is no good, but now we’re storing a system there 😉

bhauman16:10:43

@razum2um: the var thing however is attached to the start and stop of a component so not a big deal right? just like writing and deleting a file its a side effect contained within the component model

dnolen16:10:38

their app includes core.async and ClojureScript

dnolen16:10:50

pretty much essential reading for anyone who cares about load time latency

dnolen16:10:20

also why :modules really is a killer feature and more people should be using it if their final app is quite large

bhauman16:10:32

@razum2um: the system functions can take a subsystem map just as well

bhauman16:10:01

@razum2um: but I'm interested. If you see a path to make this more modular let me know.

bhauman16:10:25

please file an issue explaining your thoughts. but I do think the repl api functions are important and having a var reference gives people what they actually want.

razum2um16:10:00

ok, will try

razum2um16:10:21

anyway, thanks a lot for it

richiardiandrea18:10:15

Guys, can somebody quickly explain me why (ex-info "msg" {:tag :mi}) prints as js/Error in the repl but (type ..) return an #object [cljs$core$ExceptionInfo... and not a js/Error ?

thheller18:10:57

type in cljs returns the constructor of a type, which is a function

richiardiandrea18:10:11

or another way to say this, how can I trap\ a js/Error ?

richiardiandrea18:10:22

ah this explains everything

thheller18:10:26

js doesn't have a class

thheller18:10:52

catch everything you mean?

richiardiandrea18:10:04

no I am not in a catch

richiardiandrea18:10:10

I am building errors

richiardiandrea18:10:39

with (ex-info... would like to test if they are js/Error

richiardiandrea18:10:05

not that important, just wondering if there is a way

thheller18:10:16

uhm (instance? js/Error thing)?

thheller18:10:34

not sure if that works

richiardiandrea18:10:13

yes it works, thanks!

richiardiandrea18:10:25

I forgot about instance? 😄

richiardiandrea21:10:28

Has anybody see a

#error {:message "ERROR", :data {:tag :cljs/analysis-error}, :cause #object[Error Error: Namespace "first.namespace" already declared.]}
while requiring or ns-ing a namespace inside a PhantomJS or SlimerJS test??

bensu22:10:38

Hi @richiardiandrea! thanks for using doo

bensu22:10:50

can you show me a snippet withe the relevant code?

richiardiandrea22:10:09

well it is a bit complex, basically I am calling clojurescript core functions that evaluate forms

richiardiandrea22:10:02

for instance: (repl/read-eval-print {} echo-callback "(ns 'first.namespace)")

richiardiandrea22:10:29

this in the browser runs fine, but in phantom is not...but it is not a problem of doo

bensu22:10:34

so you want to run cljs.js (bootstrapped) in Phantom

richiardiandrea22:10:41

I tried standalone phantom and slimer

richiardiandrea22:10:52

yes basically some sort

richiardiandrea22:10:12

all the namespace related command fail

bensu22:10:27

what about other commands?

richiardiandrea22:10:45

for instance (repl/read-eval-print {} echo-callback "(doc 'println)")

richiardiandrea22:10:57

is smooth, I am about to publish a repl library and I have some tests in it...probably smthing gets hairy

bensu22:10:04

if you have an example repo, I'll try to figure out what gets called in cljs.js, follow the code, and see if anything triggers my Phantom/Slimer alarms

richiardiandrea22:10:08

7 tests fail in phantom, 5 in slimer

richiardiandrea22:10:36

k will put that out next week, time to polishing the last bits

bensu22:10:06

grazie mille

dnolen23:10:03

Covers the HTTP caching bits I wrapped up today, will cover more fun stuff later