This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-30
Channels
- # announcements (2)
- # beginners (87)
- # boot-dev (9)
- # cider (3)
- # cljs-dev (72)
- # clojure (81)
- # clojure-europe (1)
- # clojure-france (1)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-russia (212)
- # clojure-serbia (3)
- # clojure-spec (4)
- # clojure-uk (31)
- # clojurescript (82)
- # cursive (15)
- # datascript (2)
- # datomic (27)
- # dirac (11)
- # events (6)
- # fulcro (12)
- # hoplon (3)
- # jobs-discuss (1)
- # klipse (12)
- # off-topic (50)
- # overtone (8)
- # reagent (20)
- # reitit (7)
- # shadow-cljs (1)
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.
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.
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.
@bhauman re: top-level :global-exports
yeah I don’t have a problem with that - I think it’s even been suggested before
@bhauman I don’t follow that :none
is necessarily async - that’s just how the browser loader works. Just patch CLOSURE_IMPORT_SCRIPT
no?
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.
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.
I think maybe what you’re suggesting is that you use :whitespace
for initial load, and switch back to file based after that?
I’m more or less just considering out loud what it takes to be part of a greater JS tooling based project.
and it seems to boil down to a loading problem, and a consuming problem and they both seem very solvable
but I think that’s it, and maybe make sure that Closure doesn’t erase its loading stuff