clojurescript 2019-05-06

I've been updated a cljs codebase developed ~2015. The compiler is way faster now!!

Do you guys think https://github.com/janestreet/incremental is possible to build in ClojureScript? Anyone given thought to if this is the right direction and what the level of effort to build is?

ghadi15:05:03

there's a few of those incremental frameworks -- look at adapton too

ghadi15:05:19

http://adapton.org/

ghadi15:05:35

https://docs.rs/adapton/0.3.30/adapton/

Dustin Getz15:05:12

That appears to be imperative

ghadi15:05:02

I haven't used either and can't speak to them. There is some similarity with ref types

jaihindhreddy15:05:00

They seem like they're closer to reactive extensions than clojure's identities. I'm not sure you can extract a value from one of those without blocking or being clocked by anything.

vlaaad15:05:37

Hi! I wonder, is anybody here using clojurescript without figwheel? I always assumed it's THE way to do cljs: write some code, save files, watch figwheel reload stuff. But then a couple of days ago I tried to use cljs as described on clojurescript site, and was surprised, that it works just like that, with repl as in clojure. Do people use it like that? Write big applications like that?

Roman Liutikov15:05:53

I’ve heard nextjournal is using cljs repl without figwheel because Figwheel got slow for them, but in general haven’t seen anyone else doing that

vlaaad15:05:19

is there anyone from nextjournal here? care to share experience? 🙂

dpsutton15:05:17

i'd be interested in that style if there was a way to make editors play nice with it.

Roman Liutikov15:05:32

@mkvlr ping

Roman Liutikov15:05:49

@dpsutton I prefer auto reloading + connected REPL so I can explore when needed, but most of the time I don’t care and just want changes to be applied on the screen

mkvlr15:05:43

@vlaaad yes!

mkvlr15:05:49

we do use it with figwheel but also sometimes turn off live reloading and eval things on a per form basis

mkvlr15:05:25

this is an advanced feature for us, so it’s disabled by default and we only enable it when you really need the faster feedback cycles

mfikes15:05:50

I tend to like to let Figwheel auto-load when messing with UIs, but when working on businesss logic and associated unit tests, I tend to turn off live reloading for that case

☝️ 4

dpsutton15:05:45

does everyone use figwheel though? does anyone use clojurescript in the manner on http://clojurescript.org?

john15:05:06

For lib dev I sometimes use plain vanilla CLJS

👍 4

mfikes15:05:07

All the self-hosted REPLs are another example of non-Figwheel

lilactown15:05:51

I use shadow-cljs, but yesterday I had great success developing a lib just using the node-repl

lilactown15:05:34

no need to configure a build. just shadow-cljs node-repl, M-x cider-connect and I was off

mfikes15:05:05

Maybe the theme is: Live reloading's sweet spot and where it really rocks is when tweaking UIs

lilactown15:05:16

💯

mfikes15:05:30

And on the Clojure side, you end up with coarse-grained life-cycle solutions (Component, Mount)

john15:05:32

Yeah, if I'm developing a lib, I'll usually have a subproject with an application that consumes the lib. I'll definitely use Figwheel for those application bits. But for the lib, I'll often develop that over the vanilla CLJS so that it's most generic between build systems.

lilactown15:05:28

I think I remember juxt/edge eschewing hot reloading for mount/component and inline-eval

mfikes15:05:49

(The Mount stuff also works out for Node-based ClojureScript in the same way it does for conventional Clojure server apps.)

lilactown15:05:19

we use hot reloading for our Node.js app as well but it could easily be switched to use eval + mount

mfikes15:05:30

We even have Mount in a browser-based non-React app

lilactown15:05:37

in fact we use mount for parts, but nobody at work uses them in practice 😛

vlaaad15:05:09

cool, thank you for answers!

vlaaad15:05:39

I noticed there are :watch and :watch-fn clojurescript compiler/repl options, I'll try them at home, looks like something that figwheel covers...

dnolen16:05:41

@vlaaad note those don't hot reload, and aren't going to

vlaaad16:05:09

@dnolen so there is no way to hot reload using vanilla cljs?

dnolen16:05:11

REPL fundamentally hot reload

dnolen16:05:23

What Figwheel does is about files

vlaaad16:05:03

sorry, haven't tried yet, but there is other stuff that is not code that expected to be reloadable: css

vlaaad16:05:13

will :static-dir reload that?

vlaaad17:05:07

I also noticed this thing:

:src
The source directory containing user-defined cljs files. Used to support reflection. Defaults to "src/".

I thought there is no reflection in clojurescript? at least searching cljs site for reflection does not provide any more information..

dnolen17:05:34

No reloading for assets

dnolen17:05:21

Where did you find that doc?

vlaaad17:05:29

https://clojurescript.org/reference/repl-options

dnolen17:05:57

oh sorry this discussion was a bit out of context

dnolen17:05:15

that's true, the compiler does use that get information about an existing build

dnolen17:05:50

but I see how that could be misunderstand - would need to think about the wording

dnolen17:05:16

or if you have an idea, submit your CA and make a PR

vlaaad17:05:03

Unfortunately I have no idea what documentation for this parameter is trying to tell, so I don't know what how I could reword it

dnolen17:05:54

it's really not that important

dnolen17:05:34

all it's saying is that the compiler will use that to collect analysis info from :src so that interactions via the REPL work as expected wrt. to known definitions etc.

dnolen17:05:21

all we mean by "reflection" here is that Clojure (not ClojureScript) uses vars to support reflection about what's definitions are loaded, docstrings, arglists etc.

dnolen17:05:40

ClojureScript can't do it in the same way because the compilation model is completely different

dnolen17:05:20

but all this stuff is details

dnolen17:05:27

far as I recall this is all handled for you anyway

Vitor Barbosa17:05:06

Hello! One question, is it possible to have the reports for test failures (using cljs.test) pointing to the cljs source code instead of the compiled js code? I wanted to know if this is not supported or I have something wrong in my configuration. For example I'm having failed tests reported like this (firefox):

FAIL in (i-fail) (c[email protected]:374:11)
expected: false
  actual: false

And I would like to have them like with something like this:

FAIL in (i-fail) (test/hello_world/core_test.cljs:11:10)
expected: false
  actual: false

Thanks 🙂

dnolen18:05:06

I don't think currently we do anything to make that easier - though all the pieces are in place

dnolen18:05:44

it's probably a couple of days of work to tie everything together

dnolen18:05:03

@vitorqb ^

Vitor Barbosa18:05:16

@dnolen thanks 🙂.

Vitor Barbosa18:05:28

Yep, now googling a bit I even found a ticket created to address it: https://dev.clojure.org/jira/browse/CLJS-1255

enn18:05:37

https://clojurescript.org/about/differences#_concurrent_programming does not mention futures or promises, but am I correct in assuming they are not supported because of the lack of agent support? If so, are there recommended alternatives? Promesa maybe?

mhuebert18:05:13

@enn I like https://github.com/athos/kitchen-async

lilactown18:05:04

neat. I've used promesa, kitchen-async looks newer

enn19:05:36

Is there a way to just use JS async/await directly? I'm not sure how I'd define an async function.

lilactown19:05:26

an "async" function just returns a promise

mhuebert19:05:41

@lilactown kitchen-async is ever-so-slightly smoother to use. Eg. their let variant doesn't require you to wrap anything with a special form like async

👍 4

lilactown19:05:04

(defn some-fn []
  (js/Promise.resolve "foo"))

is the same as:

async function someFn() {
 return await "foo";
}

mhuebert19:05:45

kitchen-async's utilities like let, ->, do and so on all return promises, and they let you write async forms in a similar format to your synchronous code. "poor man's core.async" it is said, though I've never felt remotely impoverished

lilactown19:05:20

it reminds me a lot of your js-interop lib. just the right amount of sugar 😉

misha20:05:11

is there a way to set a name to a function programmatically but w/o macros (via metadata, etc.)? I need to dynamically return a fn, and want to set a name from an argument, so it would appear in stacktraces. Like:

(defn my-factory [fname a b c]
  (fn fname [a b c] ...))
...
(my-factory [foo-bar 1 2 3])
=> #object[my.ns$my-factory$foo-bar ...]

mhuebert18:05:38

#Also sent to the channel

@misha I’ve used Object.defineProperty for this in the past, & I think for the same purpose. eg. https://github.com/mhuebert/chia/blob/master/view/src/chia/view.cljs#L171

misha18:05:49

@U050RLRRQ thanks, will try it out

lilactown21:05:37

have to use a macro if you want stacktraces to be correct

dpsutton22:05:20

anyone ever see errors from IE11 Object doesn't support this action?

dpsutton22:05:34

in a reframe app and this works just fine in Chrome

thheller22:05:46

@dpsutton IIRC this can happen if you use js/console (ie. prn). might go away if you open the IE11 devtools

lilactown22:05:07

this almost made me quit web dev

thheller22:05:13

might be remembering wrong though

dpsutton22:05:22

i've got them open because i'm logging. as far as i can tell it just dies when it shouldn't. a reframe event is called [:invoke f arg] with the arg coming in and invoke just calls (f arg). as far as i can tell it doesn't call it but rather throws this error from bidi for some reason

lilactown22:05:02

all of my googling tells me it might be using a constructor that doesnt exist

dpsutton22:05:16

i read somewhere about CustomEvent and ie11 not having that

dpsutton22:05:28

but i dont' know what that is. although there seems to be some custom event package in re-frame

lilactown22:05:50

you said it fails in bidi. does it not have a stack trace?

dpsutton22:05:06

its async for some reason.

dpsutton22:05:27

also having to do this through browser stack and running figwheel locally and its terrible 😞