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) => ({
    /*...*/
  })}
</Droppable>;

(def droppable (r/adapt-react-class js/ReactBeautifulDnd.Droppable)

[droppable {:droppable-id "some-droppable"}
     (fn [provided snapshot]
       ...)]]
 ...

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

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?

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.

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

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

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.

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 https://dev.clojure.org/jira/browse/CLJS-2339. 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 ....)]

Yes.

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 https://code.thheller.com/blog/shadow-cljs/2017/11/10/js-dependencies-in-practice.html 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?

What is this new symbol :>?

@grounded_sage https://github.com/reagent-project/reagent/blob/master/docs/InteropWithReact.md#creating-reagent-components-from-react-components

Ah I see it's Reagent specific.

Thanks @emil0r 🙂

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

As mentioned by React docs, https://reactjs.org/docs/react-component.html#props, 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, ...rest }) => console.log(rest);

basically that rest bit

I tried the following

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

but it doesn’t like it

use sequential destructuring

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

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

yeah

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

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": https://clojurescript.org/community/reporting-issues

@mfikes All right, I’ll try..

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

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

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

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 [] [:div.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: https://github.com/binaryage/dirac/blob/master/src/shared/dirac/shared/pprint.cljs

Was sad to see that format fn was not implemented in cljs, then I found cuerdas.core/format! https://stackoverflow.com/a/49392549/1184248

there is also goog.string.format: https://google.github.io/closure-library/api/goog.string.format.html

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 ---- java.io.FileNotFoundException: 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

any ideas?

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

0.5.7 was broken: https://github.com/binaryage/cljs-oops/releases/tag/v0.5.7

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:

(go
  (let [channel (http/call with-some-params)
        data (:some-key (<! channel))]
    data))

@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

Hi there

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

https://stackoverflow.com/questions/16894465/extend-protocol-in-clojurescript-to-get-value-from-native-js-object

but it is dangerous ^

danger is my middle name

hah

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

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

@lee.justin.m a javascript example https://youtu.be/I7IdS-PbEgI?t=1016

@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