Clojurians
#cljs-dev
<
2018-12-30
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

bhauman00:12:34

Another interesting problem when it comes to loading an opt none compiled cljs application in JSC is that it is an async operation. Which means that we cannot define and register the Root React Native application component in our ClojureScript application code. The React Native application loader appears to expect an RN application root to be registered synchronously upon the first loading of the compiled application bundle. Re-natal solves this by registering a proxy root component immediately, which gets updated once the cljs app gets loaded.

bhauman00:12:54

Creating an initial npm loadable bundle is an interesting solution to the general problem of how does CLJS relate to the larger JS ecosystem. Also the recent work that has gone into the closure debug loader (i.e. goog.base) for es6 module support could play a role as well.

bhauman00:12:35

All in all, working on this React Native CLJS bootstrap problem is providing a really valuable opportunity to look at CLJS/closure and its relation to the greater JS world.

dnolen20:12:30

@bhauman re: top-level :global-exports yeah I don’t have a problem with that - I think it’s even been suggested before

dnolen20:12:54

@bhauman I don’t follow that :none is necessarily async - that’s just how the browser loader works. Just patch CLOSURE_IMPORT_SCRIPT no?

bhauman20:12:52

It’s only necessarily async under the loading conditions available in JavaScript core under react native. And I patch Clojureimportscript to to use the fetch to allow this loading. There isn’t a blocking load option that I’m aware of. I’m sure it’s possible to alter the RN bridge native code to allow a blocking load of some sort. AFAIK async is what’s available out of the box.

bhauman20:12:30

Big thumbs up on top level global-exports.

dnolen20:12:47

I guess I’m somewhat confused about RN, but I haven’t done much RN

dnolen20:12:59

so RN still assumes you make a bundle and load one thing

dnolen20:12:08

I don’t follow Creating an initial npm loadable bundle

dnolen20:12:24

how’s does that relate to the RN async problem?

bhauman20:12:58

That wasn’t very specific

bhauman20:12:10

What I meant is that if a tool generates an initial cljs app bundle which contains all the source to be loaded that would intact be bundled into the initially loaded JS bundle and thus the loading operation would be async.

bhauman20:12:24

Well that’s still not very clear

bhauman20:12:49

Switching to a keyboard

dnolen20:12:19

I guess I don’t understand how that’s different from simple or whitespace?

bhauman20:12:29

in a way its not

bhauman20:12:54

but I still want goog.base in there

bhauman20:12:04

to support runtime loading

dnolen20:12:12

isn’t goog.base in whitespace?

bhauman20:12:52

very well could be

dnolen20:12:55

I think maybe what you’re suggesting is that you use :whitespace for initial load, and switch back to file based after that?

bhauman20:12:12

yes thats the general idea

bhauman20:12:47

but in a form that plays nice with npm require semantics

dnolen20:12:20

hrm I guess I don’t see a problem here?

dnolen20:12:30

what is clashing with require?

bhauman20:12:53

yeah probably nothing

bhauman20:12:15

I’m more or less just considering out loud what it takes to be part of a greater JS tooling based project.

bhauman20:12:27

and it seems to boil down to a loading problem, and a consuming problem and they both seem very solvable

bhauman20:12:49

or already solved

dnolen20:12:48

hrm I wonder about :whitespace-incremental

bhauman20:12:04

oh that’s interesting

dnolen20:12:10

that would probably faster to load across the board

dnolen20:12:18

and then switches to incremental after the first time

bhauman20:12:32

absolutely

dnolen20:12:32

and then tools downstream don’t have to reinvent the wheel

bhauman20:12:00

yes, the loading problem dissappears in general

dnolen20:12:22

might try to hack on that

bhauman20:12:14

thats fantastic

bhauman21:12:21

hmmm would you include the deps and cljs_deps in the whitespace bundle?

dnolen21:12:25

I think :whitespace should probably include everything just like :simple & :advanced

dnolen21:12:42

I don’t remember the state of :whitespace since I so rarely use it

bhauman21:12:13

I specifically mean the addDepedency calls in the cljs_deps.js

bhauman21:12:43

those aren’t normally there in :whitespace I’d assume

bhauman21:12:17

but its important info that the REPL and reloading needs

dnolen21:12:17

right we would need to add those

dnolen21:12:47

but I think that’s it, and maybe make sure that Closure doesn’t erase its loading stuff

bhauman21:12:37

absolutely, and check that those COMPILED vars are in the right state

bhauman21:12:51

oh AND … closure defines!!

dnolen21:12:10

might just be easier to do our own whitespace thing

dnolen21:12:16

COMPILED is annoying

dnolen21:12:58

hrm but let me try

bhauman21:12:36

hmmm and then there is a question of a full reload

bhauman21:12:48

like a browser refresh

bhauman21:12:11

in that case we are delivered an out of date codebase

dnolen21:12:22

could compile whitespace again after the dep nses are recompiled on another thread

bhauman21:12:41

thats very interesting,

bhauman21:12:57

yes on another thread because it really doesn’t matter if its latent

dnolen21:12:50

ok nice var COMPILED=false; with :whitespace

dnolen21:12:55

so just need to make sure the dep graph gets in there along with the flags for whatever is already loaded I think

bhauman21:12:43

I think the provide calls handle that already ??

dnolen21:12:56

oh, hrm maybe you’re right

dnolen21:12:10

so just need the dep graph then

bhauman21:12:31

and perhaps the closure-defines

dnolen21:12:49

definitely, since COMPILED is false