I keep wanting to refactor the cljs.repl/repl* code into a constructor for the functionality (read, eval, print, prompt, etc) and the bundled environment data and separate it from the loop. This would be a boon to piggieback with it's ugly duckling "setup a repl on every eval" behavior. There is also the possibility of factoring out the setup code into a group of functions that can be re-used. I guess the point is that the setup code is very valuable and it would be nice to have a convenient way to construct an eval function, or a type that we can call eval on.

(.then (get-json-promise) #(js/console.warn (.-url (first %))))
(.then (get-json-promise) (fn [data] (js/console.warn data) (map #(js/console.warn (.-url %)) data)))

@debug: map returns a lazy seq. If you want side effects you probably want doseq. See this stackoverflow for an example: http://stackoverflow.com/questions/21069188/how-do-i-perform-a-function-with-side-effects-over-a-vector

@noonian: Thank you very much! 😄

@debug, as a quick fix, you can also replace map with run!

[figwheel "0.5.4-SNAPSHOT"] gives me an error about :compiler being a wrong configuration key. Has something changed, or did I do this wrong all along? @bhauman ?

can't find anything in CHANGES about it

replacing it with :build-options (as indicated in the error message) worked though. To be clear, I'm talking about running figwheel-sidecar.repl-api/start-figwheel!. With 0.5.3, the :compiler key worked just as well, and I don't remember seeing a warning about it.

@bendlas: I really had to choose one or the other.

Unfortunately it may change back to compiler in the future to stay consistent. 😞

fine by me, I just wasn't aware of the alternative.

does cljsbuild support both?

nope 🙂

well, with such good error messages, it's no biggie

but you might also want to log them, because I didn't immediately discover it, due to running start-figwheel! in a future

and by the way, big Thank you and big Up for figwheel 🙂

@bhauman changing cljs.repl/repl* just isn’t going to happen, all that stuff is more or less frozen in stone at this point.

making some new thing that piggieback can use is the only thing that would be considered

that works 🙂

the surface interface of what exists will not change

oh absolutely

@pesterhazy thanks! Will try that

I would never change the surface interface

a constructor function that takes ReplEnv and returns an eval method or something like that was all that I was thinking of

there are some subtle problems here - mostly around dynamic binding

particularly *unchecked-if* which works across multiple forms

so the person creating such a ReplEnv has to know about it and handle it

alrighty, I will keep that in mind

when I look at it

right now piggieback is pretty damn slow and lots of people are using it

yeah, I can imagine but I already looked at that problem once

not going to look at it again

oh for sure

I was planning on looking at it.

also it’s not clear to me why it needs to be done at this level at all

i.e. why not put the framing stuff around Socket REPL connected to a ClojureScript REPL and separate all these problems

https://github.com/puredanger/replicant

I have been thinking about that as well.

And I get that approach completely. There is no argument here, I do think that approach can lead to tools opting to parse strings for errors and warnings and such.

@bhauman: I also don’t see why you need to be thinking about this 😉

the tools to fix all these problems have been sitting around for a long time now, anyone can work on this - especially people without full plate of tooling work

this is true 🙂

yeah the last commit to piggieback was in 2015

this means no one is working on the problem

I was thinking I could fix it pretty easily

if you’re annoyed your REPL is slow it is time to lift a finger

its not "that" slow, but its strangely latent

well not strangely

🙂

Clojure doesn’t construct anything when creating the evaluation environment

ClojureScript does a ton of work

for known reasons

but as I said this isn’t the root problem

the root problem is piggieback

and stubborn need to recreate the environment

I don’t think trying to work around it desirable at all

adding stuff because one tool has a questionable implementation seems ill advised

anyone using secretary for frontend routing here? help needed

a likely simpler idea - nREPL / Socket REPL adapter

then you stop caring what ClojureScript does

case in point

when I run Figwheel on a remote box

how long does it take to get a new REPL?

instantaneous

how to make (secretary/dispatch! "/login”) to change URL? changing URL will fire dispatch and according handler. but manually fire dispatch won’t change browser url 😞

@dnolen: currently grokking the different implications of this... will let it ruminate

@rui.yang: there might be another way, but I just .setToken on the goog.history.Html5History

this will trigger the routing though so be sure to break the cycle as appropriate

@darwin @bhauman so something else that’s been on my mind related to tooling - it seems the need to inject something for setup into the build is pretty high

things that would otherwise require the user writing error prone connection code etc.

so I’m open to the idea of making some standard way to get thing X loaded and setup before user code

oh like injecting figwheel client

I know people already have workaround or what not, but if people have some strong opinions about how this should be handled - I’m listening

@bhauman: yep

or https://github.com/binaryage/cljs-devtools

If you create an issue ping me. I'll look at what figwheel is doing and see if I can help.

k will do

@bendlas: thanks for the tip

will try it out

really like the idea though

@bendlas: what I want to do is to switch pages in my SPA. the correct way is call History.setToken to trigger secretary/dispatch!, instead of calling secretary/dispatch directly. thanks for the tips

@rui.yang: sure, np

Ok, I just gotta come in here to say how much I love cljs and reagent. Trying it for the first time to muck around on the front end, and I love how the combination of cljs and react just basically abstracts away all the ugly of dom manipulation. Such happy.

hello. im trying the modern cljs tutorials

and i get this message

`

what exactly does that mean

@rui.yang: you might also want to have a look at pushy, which integrates goog.History with well-known routing libs

https://github.com/kibu-australia/pushy

@bhauman: figwheel fails when trying to show the warning dialog for warninged code: when calling format-line from heads-up/display-system-warning, a map gets passed, and subsequently goog.string.indexOf gets called on that

hmmm, did you do a lein clean? Just making sure before I check it.

and reload the browser?

let me try that lein clean real quick

nope, str.indexOf is still not a function

I'm using it with devtools though

commented it out, reset-autobuild still there

display-system-warning isn't called with a map

The old display-warning composed over display-system-warning. it doesn't do that anymore.

strange, i see it called with a map with :ns :file :extra :column .... in my debugger

with current snapshot

have you tried it without dirac?

no dirac, just devtools

i commented it out (the require too), did a reset-autobuild and it persisted.

rechecking ....

i do run figwheel-sidecar from code, though

yeah you are running the old client code for sure

old client code with new sidecar messages, won't work

ok, target folder is gone

figwheel-sidecar version is 0.5.4-SNAPSHOT

starting up the server .,..

hold it, deleting figwheel from .m2, restarting ...

oh ... snapshot depends on 0.5.3-2

just saw it in the download

overriding figwheel version in project.clj too

nope, you are depending on 0.5.3-2

@dnolen: that would be great, but I think the problem is two fold: 1) how to make sure init code for different tools runs in particular order before user’s own code which runs last (also the user should be able to specify that order explicitly if needed) 2) how to provide configuration to individual tools I think the first problem would be solvable by allowing compiler option :main to accept a list/vector of namespaces. cljs-devtools would provide a special “bootstrapping” namespace which would contain (devtools/install!) call, people would put it there before their own namespace(s). I think this is something @thheller already proposed in some JIRA ticket. The second problem would be more work. I would like to see something like “environmental config” which could be passed in compiler options and tools could configure themselves based on it. Right now, the best practice for cljs-devtools installation is described here: https://github.com/binaryage/cljs-devtools/blob/master/docs/install.md#dev-builds And the tool can be configured by altering default prefs before calling (devtools/install!) https://github.com/binaryage/cljs-devtools/blob/master/src/devtools/prefs.cljs

no, i depend on figwheel-sidecar 0.5.4-SNAPSHOT, which in turn depends on figwheel 0.5.3-2 apparently

it doesn't

ok sorry, my dev meta-dependency depends on it and leiningen chose that one, sorry ...

classic transitive dependency fail 😞

that works now

the new dialog is really shiny

kudos

@darwin: just fyi in case you don't already, boot-cljs does exactly what you said, the same convention could be brought to core: https://github.com/adzerk-oss/boot-cljs/wiki/Usage#multiple-builds

@darwin not actually interested in 1) at all

use component

@dnolen: @darwin a thunk of code custom init code that runs before :main is required, could go a long way, this allows for a great deal of expression

I only care about simple cases where ordering isn’t going to matter

REPLs / browser dev stuff

anything more complicated we’re not going to deal with

hm, “use component” means “force user to use component”, because me using component does not help if user is not starting his app via compoenent model and integrate my component into his components deps properly

if you need component use component

every tool should work as lib so user can solve their own problems

the only thing I’m interested in is for newbies who want to just try something

they can copy and paste some simple build config - and we provide a easy hook for these basic cases

anything more than that - no interest

btw. just curious, would you consider forking cljs-devtools into cljs.devtools namespace (a new project) and make it part of “out-of-box” clojurescript experience? I think it got mature enough and I would be willing to make changes to make that happen

@darwin that’s interesting - but I think tooling stuff probably should evolve freely outside of the various restrictions around official projects

as far as I can tell - it takes a long time to know what is or isn’t going to work

sure, no problem, I’m quite happy with current setup

@darwin: I've been thinking about including it with figwheel as configurable option

I need to use it for a bit first

@bhauman: yeah, anything which reduces friction for new users sounds good to me, figwheel is first thing people install and if they get cljs-devtools for free, better

yeah as long as your happy with it, I'll explore it

cool

but you will still have the problem “how to run devtools/install! before any user’s code”, without user’s assistance, you cannot do that AFAIK

I can do it

how? via lein plugin?

figwheel already injects code

it injects itself in builds with :figwheel true

so I just inject a little more

its kinda perfect

ok, great

another topic: I want to integrate figwheel's nREPL with Dirac soon, something along these lines: https://github.com/binaryage/dirac/blob/master/docs/integration.md I think it should work in theory even now. But I want to make sure, the new improved error/warnings could be displayed nicely in Dirac when joined with figwheel REPL

the idea would be to start Figwheel with nREPL as usual, but include dirac nREPL middleware and then join it with Dirac REPL as described in the document

When running tests that use cljs.spec (using lein-doo) It prints the newlines as escaped in the validation errors, how do i tell it to print them instead?

I’m making a website plugin system. [cljs.core, my-base-code.core -> js] <<load scripts << [p1.cljs-> js] & [p2.cljs -> js] Is it possible to compile cljs into a js file without including dependencies of require’d namespaces. So I can then just include the plugin js files and they will work because cljs.core and other libs will already be loaded. I believe LightTable does something similar for it’s plugins, I’m just not sure if this is a compiler option or more like defining my cljs code as externs… Any advise would be appreciated!

Is something changed since this thread started and where is a way to simplify patterns? https://groups.google.com/forum/#!topic/clojure/13gOQgzGEMk

@dragoncube: nothing has changed

I’m trying to use @ra’s clojurescript-npm to write a script. The following does what I expect if entered line by line into their cljs repl:

But this next file, in js, is not the right way to run it as a script — it exits with no output:

I’m curious where my mental model is failing

@dnolen: I see, thanks

@mathpunk looks like you need to send the data somewhere

Try process.stdout.write(result);

I'm having trouble finding a good explanation for how Hoplon and Reagent/Re-frame compare. I know Hoplon uses a "spreadsheet" metaphor with Javelin and doesn't use React, and Reagent uses FRP and React, but spreadsheets are sort of FRP, aren't they? How does the metaphor diverge? I want to make an app where much of the code I could reuse for the web, my phone, and the desktop, though this will most likely be a desktop-first app via Electron. I want to make a personal knowledge base (https://en.wikipedia.org/wiki/Personal_knowledge_base), so I want to be able to query and explore a multimedia graph database rendered in canvas or WebGL (I'm not sure of the GUI side yet, but the data structures side is pretty well-defined for me). I want to have the database be immutable and versioned, so I've been looking into using DataScript as the base for my database. How would DataScript fit into Hoplon or Reagent? Can you help me understand the pros and cons or differences between Hoplon and Reagent for someone who hasn't used React or ClojureScript before? I use JS a lot, but I don't have any real experience with the React or ClojureScript ecosystems nor even Clojure, so I don't quite know why I would want CLJS-flavored React any more than I know that I would want Javelin. I apologize for requesting such a comprehensive explanation from such ignorance. There's so much information to understand that it's difficult for a newcomer like me to make sense of it and make a good judgment on which framework/library is best for me. I have dabbled in different Lisps but haven't used any for real projects, though I've made a Lisp interpreter. I say this so you realize I'm not a complete newbie when it comes to Lisps in general, though I'm definitely a newbie to Clojure(Script).

Hi everyone. New at reagent. I defined a component, giving it a :name prop. Something like

(defn my-comp [name] [:h1#title {:name name} name])

(dommy/listen! (dommy/sel1 "#title") :click clicked)

(defn clicked [] ...)

@gamecubate: there is a #C0620C0C8 channel

@mhr: there’s a #C08BDAPRA & #C0620C0C8 channel, probably best to ask that question in the respective places

Yes I saw and (double) posted (here). Not so deep on Slack yet. Thanks will keep it to one channel.

<switching over to reagent>

@ericfode: might need @bensu to chime on that when he has time

@gamecubate: you probably want to attach your event listeners through react/reagent by providing an :onClick property (might be :on-click in Reagent). If you do it that way you will already have the :name property in scope.

@dnolen: kk Thank you!

Understood but I want the handling to be done by a third-party, a mediator, who knows whether or not component clicks should be processed or, depending on some app-state property, ignored.

thanks @dnolen, I figured I'd get more eyeballs here, but I'll cross-post there too

I have a quick noob question. I think it's a boot-reload question but I'm not 100% sure so I'll post here, please let me know if there's a better channel for it. I'm using boot on this small project and I have several modules, let's say I have core.cljs which imports module A which imports module B (core <- A <- B.) I make a change in B and only that module gets reloaded, but I want the reloading to "bubble up" through the modules up to core.cljs, is that possible? I want this because core.cljs has a "renderer" that needs to be reload in order for me to view the changes made in any of its submodules.

maybe I should use something like on-jsload?

@volrath: Yes, unfortunately you currently need to use on-jsload to call the renderer, because boot-reload doesn't use dependency graph to reload dependent namespaces

noted, thanks for the quick reply 🙂

hey @dnolen ! @ericfode I haven’t tried cljs.spec yet. Do you mind filing an issue on doo so that I update to the latest cljs version and make sure it properly works?

@bensu np

there was a bug with multi-arity fn spec verification caught by Oliver George now fixed in master

if people have some time please give it a spin

would like to cut a release tomorrow with this fix