Fork me on GitHub

newb question: Any reason it's resources/public and not just public ?


ok figured it out, i guess, figwheel requires it.


@quang Java allows you to package resources with you into a jar file. That's where the resources directory comes from. public is the default directory for things you want to be publicly accessible (through a web server for example)


I'm trying to use cljsjs/react-beautiful-dnd in my project and the documentation mentioned I shall pass a function as component's children:

The React children of a Droppable must be a function that returns a ReactElement.

<Droppable droppableId="droppable-1">
  {(provided, snapshot) => ({
How would that translate into ClojureScript?
(def droppable (r/adapt-react-class js/ReactBeautifulDnd.Droppable)

[droppable {:droppable-id "some-droppable"}
     (fn [provided snapshot]
^^^ will complain about passing a function as children


Ok, this is as easy as providing :children key in comp's props"

[ droppable {... :children (fn [x y] ...)}]


@smogg even easier [droppable (fn [x y] ...)]


oh I saw that you tried that


what's the error you're getting?


I don't know why that shouldn't work

Mikko Harju11:03:06

I found the most peculiar bug in Clojurescript/Figwheel/Fireplace… If I have npm-deps in my dev -build, every other evaluation takes something around 10 seconds. Has someone else experienced anything similar?

Mikko Harju11:03:40

It evals two forms, {:msg-name :repl-eval, :code "cljs.core._STAR_print_namespace_maps_STAR_ = true", :figwheel-version "0.5.15", :build-id "app", :callback-name "figwheel_callback_71846"} and then there is 10 seconds of pause before the actual form to be evaluated, for instance just (+ 1 1)


I have been away from Clojure for a while @mikko so I may be doing it wrong. But I literally have a minimal Boot setup with no figwheel and I'm trying to use React Native Web. Which requires npm-deps. I'm getting anywhere between 2-70 second builds.

Mikko Harju11:03:21

Hmmm, oh so it might be that the javascript-compilation step takes the extra time? I already checked that within FigwheelEnv:s (-evaluate) it takes the same amount of time for both of the forms, so the time is took between those calls

Mikko Harju11:03:42

Compilation taking extra time would actually make sense why this is happening

Mikko Harju11:03:56

Since it evaluates the compiled javascript form


I am assuming this is because it is going through Nashorn? I don't know. So much has changed in Clojure ecosystem.

Mikko Harju11:03:42

I’m not familiar with the compiler how it does its thing. The strange thing is that this is consistently fast every other eval, slow every other. If I cancel the evaluation midway when it’s slow, it’s slow until I eval it completely. Then the other invocation is fast again (the evaled form can be different, it does not matter here)


@mikko If you can catch the compiler in one of the 10-second pauses, using jps first to find the process ID, and then jstack during a pause to get a stack trace, that might help isolate what it is doing at the time.


@mikko There is a comment at the bottom of If you learn more, perhaps open a new JIRA with that info.


@pesterhazy That'd result in an error similar to: objects are not valid as a react child


@smogg Have you tried [:> js/ReactBeatufiulDnd.Droppable {:roppable-id ".."} (fn ....)]


the combination of :children key set along with returning a component using r/as-element from that function is the only thing that seems to be working


[:> js/ReactBeautifulDnd.Draggable {:children
                                                       (fn [provided snapshot]
                                                         (r/as-element ...


@smogg think this must be an issue with reagent


OTOH i didn't know you could pass children using :children


I'm reading and am a bit confused. Is (:require ["thing" :as thing]) syntax a part of clojurescript itself or does shadow-cljs pre-process the source files?


It is official CLJS syntax but the feature actually works reliably in shadow-cljs. :npm-deps of CLJS itself is still a bit wonky and unreliable.


I see. Thanks!


What is this new symbol :>?


Ah I see it's Reagent specific.


:children property is same as providing list of children after props map


As mentioned by React docs,, props.children is usually defined by providing children in JSX/or hiccup etc. but it can be provided in props map if not provided elsewhere


just wondering if there is some cljs.pprint replacement which would allow me to limit max string length inside printed output, looked into fipp but didn’t see that option there…


@darwin FWIW, Fipp is extensible, so you could get away with defining your own visit-string. (I suppose you'd have to delegate back to the base implementation for all of the other IVisitor methods.)


hi everyone. is there an equivalent to this destructuring in cljs?

const destructure = ({ a, b, c, }) => console.log(rest);


basically that rest bit


I tried the following

(defn dest [{:keys [a b c & rest] }] ... )


but it doesn’t like it

Alex Miller (Clojure team)15:03:12

use sequential destructuring

Alex Miller (Clojure team)15:03:23

(defn dest [a b c & rest] ... )

Alex Miller (Clojure team)15:03:03

the {:keys ...} is associative/map destructuring for when your input is a map


yeah, I have a map as an input


just like in js I have an object


I guess there’s no equivalent


I couldn’t find it in any docs 😄


You could do it without destructuring: (defn dest [m] (println (dissoc m :a :b :c)))


Depending on the usecase.


yeah, but I was just wondering. I’m creating a little presentation on ClojureScript and I was just comparing a few js examples to Cljs implementations


yeah there's no function to "split" a map into a map containing :a :b :c and one containing only the rest


👍 thanks


IME in practice that need does come up sometimes but not that often


it does when you want to pass down the rest of the map to another component for example


but then again, in cljs you would structure things differently


right that's the use case I've had as well though often unknown keys are just ignored so it doesn't matter that much


I was just gonna say that functions (or components in this case) will only extract what they need


1.10.217 is available, we’re getting very close to the big release - please test

Mikko Harju15:03:34

All right, I’ll try that if I can 🙂


@mikko Cool. If you can in any way produce a minimal repro and file in JIRA, that would help immensely in resolving whatever is going on. I couldn't find a repro. See this for definition of "minimal":

Mikko Harju16:03:34

@mfikes All right, I’ll try..


Thanks... that would lead to the greatest chance of resolving it

Mikko Harju16:03:56

I’ll build me a version of cljs from master?


Yes, you should as described in the web page


Also @mikko if it makes it easier, even though the page doesn't mention it, minimal repros using the new cljs.main are also accepted

Mikko Harju16:03:56

OK, that is completely unknown territory to me. Maybe this would be the appropriate time to try that stuff out but 🙂

Geoffrey Gaillard17:03:56

Hi everybody ! I have a pretty big cljs app (900k in :advanced mode and gziped) and I'm trying to make it smaller. I have a bunch of pages like :page/home or :page/about and I'm routing with a multimethod like (defmethod get-view :page/home [] []). IIRC, defmethods are not removed by the closure compiler dead code elimination. Is there an idiomatic way in the cljs world to dispatch to various pages/components while preserving the advantages of DCE ?


you want :modules


that’s our integration with Google Closure code splitting feature


Guys. Are there anyone who is familiar with cocos2d with clojurescript ?


Are there any mature Library for developing cocos2d with cljs ?


just for record, here is a working solution to my problem above using fipp, needed a way how to pprint, but shorten long strings, thanks @mfikes:


Was sad to see that format fn was not implemented in cljs, then I found cuerdas.core/format!


I just figwheel 0.5.15 moved a project from OS X to a windows machine and I'm getting a compilation error with a packaged called oops:Failed to compile build :client from ["src"] in 8.959 seconds. ---- Could not Analyze resources/public/js/oops/config.cljs ---- Could not locate cuerdas/core__init.class or cuerdas/core.clj on classpath., compiling:(oops/helpers.clj:1:1) ---- Analysis Error : Please see resources/public/js/oops/config.cljs ---- Figwheel: initial compile failed - outputting temporary helper application to resources/public/js/client.js


@jrbrodie77 are you using the latest version of cljs-oops 0.5.8?


i mention just because its bitten me before. any chance you haven't committed recently added files? I've for sure pushed some broken builds before in the past.


@darwin I'm using 0.5.8. I think that the exact package is a red herring. I just factored out oops and now I'm getting a similar error regarding parsley.


Is there anyway to destructure javascript objects? It’d be very handy when you have to pass a callback to a javascript library.


(let [{:keys [k1 k2]} (js->clj js-obj :keywordize-keys true)] ...


might work


Is there a way to return a value from a go block in cljs? I have something similar to this:

  (let [channel (http/call with-some-params)
        data (:some-key (<! channel))]
Obviously this returns a channel. However. I'd like to have block and return a value


@john thanks yea that does work but that’s precisely the thing I was hoping to avoid 🙂 if i’m going to do that it’s easier to just do (.-k1 js-obj)


oh, js-obj is already a reserved word for a function


oh well yea but you know what i mean


Well, destructuring isn't always the fastest method


@petr you can’t really block in javascript because it is single threaded. i don’t even think the blocking take operators are is implemented


i don’t care about speed


Yeah, I noticed the <!! operator was missing


I mean programming-wise. Destructuring usually makes code more succinct. In your example, maybe not.


true. the syntax for destructuring maps is just about the only thing I don’t like in cljs as compared to javascript


@petr you just have to deal with the fact that i/o is async in javascript and therefore is async in clojurescript


but it is dangerous ^


danger is my middle name


that’s completely amazing although i don’t really understand it


read clojurescript compiler source code 🙂 how get and get-in are implemented 🙂


cool kids don't use js objects 😉


unfortunately there are like 500,000 very uncool libraries on npm

🤓 4

That few?


There are a lot of ways to tweak cljs so that you can essentially just easily write raw js in lisp. By not building those "easy" paths down the road of mutability, we are helping ourselves avoid pain through conventions, moreso than what is and isn't possible. So like @darwin said, careful making mutable objects that look like the good stuff when they're not.


But if you're feeling naughty, check out extending string too 😉


I’m a simpleton hacker who has never really understood the appeal of immutability in a single-threaded environment except as a performance enhancement for deep comparisons, but I don’t need to start a debate that I certainly can’t win.


well, 1) there's still "concurrency" and, 2) when threadish things come to JS, we will be here waiting 🙂


And 3) it's more about the mental model that immutability provides, than just the concurrency guarantees, which my mind is more used to now, so I'd prefer it anywhere on any host


oh okay i get the thing that darwin posted. so does detructuring use that same protocol?


@lee.justin.m it decomplects time and value


which is also useful in single-threaded enviroments


@devicesfor I probably don’t really understand what that means. The standard model in reagent, for example, is to mutate a big ol’ state atom.


ILookup is a protocol for finding things in objects, like things in maps. Maps implement -lookup which is what destructuring uses to pull things out of maps.


When you do a get on a map, underneath it is calling -lookup


yea i think i get that. it was this part that i wasn’t sure about before: which is what destructuring uses to pull things out of maps


obiously there’s some code in the bowels of the cljs compiler that implements that


@lee.justin.m immutable data removes complexity, since you can't edit it, it makes things simpler, mutating creates lots of problems


destructuring is just using the same tools you use to get things out of maps


and as long as you implement a similar interface, it'll blindly call the methods it expects to exist


@devicesfor Yea people say that a lot but I can’t think of a single instance of web code I’ve ever written that would have been helped by it. I’m sure you’re right. It’s just that I’m a concrete thinker and need concrete examples or I don’t understand it. Plus the “immutability” of the state atom seems sort of hollow give that you are actually mutating it all the time. I’m certainly not against immutability, it’s just that its much easier to understand how it can save your bacon in a multithreaded environment.


@clojurians-slack cool thanks. i probably won’t mess with that since it sounds like a Bad Idea, but I like that it is possible


eh, it's not really true. A single javascript execution context is single threaded. And a only a single thing will be editing an object at time. But in js, if you don't protect your data, then other processes can still clobber it.


and under the hood, the browser is employing many threads and many of your particular js contexts of execution, while not necessarily multi threaded, need not actually process in order.


a lot can go wrong


but yea, run to completion semantics in js eliminates large classes of errors that we don't have to worry about


i agree with all that, particularly the last part. 🙂


gotta run, ttyal


@devicesfor thanks that’s a good talk. i was familiar with the flux performance enhancement thing (which is what I was referring to above). The intervening mutator example right at the beginning is pretty compelling. Definitely easier to reason about a program when variables are referentially transparent or have an @ before them to let you know they might not be.


@ is a "killer feature" 😂


it's a very succinct interface between two asynchronous contexts


even if the two contexts aren't asynchronous, by building the second call to deref on every place you might mutate, it allows you to do that easy separation of contexts.


what happens on the other side of that -deref call could be on the other side of the world, doesn't matter.


i just learned about how deref is used in clojure promises, futures, vars and refs, but i’ve only seen it used in cljs with atoms. maybe there are other cool things you can do with it?


one of my problems is that the history of cljs is clojure people making clojurescript but i went straight from javascript to cljs. that’s a disadvantage when reading docs sometimes


clj is like a hygienic transformation environment where potentially unhygienic, mutable transformations are logically partitioned off behind a wall of deferrability. Some of that whole abstraction does pay dividends in js land. David nolen proved that with his "react faster than react" thing a few years ago.


But really, how long do you think js land is going to stay this way, without shared memory and threads?


The only reason everyone isn't using web workers is because the abstraction is too hard for beginners to solve simple concurrent problems.


@lee.justin.m well fwiw, I was doing JavaScript for 6 years before I started contributing to ClojureScript - there’s a learning curve for sure - but honestly I think from one perspective, I think the barrier of entry for a JS programmer is lower than for Java programmer


one problem is I started doing JS back when it was pretty hard, IE 6 was still important


so a lot of the new stuff that JS stuff people came up with just didn’t make any sense to me


still doesn’t 🙂


@dnolen oh yea i’m not whining. i tried to circumscribe my statement to the very limited “disadvantage when reading docs sometimes”.


in particular clojuredocs is clojure-focused


sure but it’s an odd thing to say in the sense that every community is navel-gazing


JavaScript stuff is JavaScript focused


and some of the “deeper” books are clojure-focused too and i’m too lazy to try to sort through what’s useful for cljs and what is really clojure focsed


right that’s interesting - but I personally feel the gap between CLJS and Clojure is pretty boring


enough that the most important things about Clojure carry over to ClojureScript and vice versa


there’s a reason ClojureScript bootstrap wasn’t that hard


maybe you’re just better at this than me. i feel like i run into stuff all the time that is clojure specific. there are a number of libraries and concepts that are described in the context of threads, for instance


it’s not a big deal. it was just an offhand comment. really learning clojurescript has been a delight.


@dnolen you're not a good example of a js dev coming to cljs 🙂


well it’s just my own perspective and that’s problematic for lot of reasons - still I think the neat thing about CLJS -> CLJ (which is a new phenomenon)


is that it’s like whoa - I can upgrade from single-threaded semantics to multi-core


and it’s not a hard transition


yeah, I think that's super interesting. @lee.justin.m have you tried clojure, as a result of getting into clojurescript?


not yet. my backend is just a bunch of javascript glue between an rdbms, elastic search, and some batch processing junk that runs on express. it doesn’t really cause me as much pain as the frontend so i went front end first.


also in a previously life i dealt with massive concurrency in c++ and it was a nightmare that we eventually wrote in an async style. with node, you’re there already so i have a degree of comfort with that style


where concurrency = multithreading