Fork me on GitHub
Lone Ranger12:08:08

so question about code-splitting use cases. One of the projects that I work on is primarily a Python-Flask server side application and I've convinced them that clojurescript is an absolute necessity (and they went along with it woohoo!). I do a lot of one-off projects, replacing one page at a time with an SPA-like cljs webapp thingy. Turns into a lot code duplication etc. I was thinking, hey, why I don't I just combine all my little clojurescript projects into one big ol project and then dispatch by route? Okay so onto the question. Let's say I do code splitting a I have the "core" modules which does the dispatching, and I'd like to lazy load the code for each mini-app. Is the technique for this to dynamically add a script tag to the dom, or do you do a dynamic (require 'some.code)?


@goomba there's a code-splitting guide on the website


but you should have the right expectations about how code-splitting works


it's not for "mini-apps"


and it doesn't work at library boundaries


it works at method / fn level


meaning it attempts to move granular functionality into the right part of the split


it should be updated to talk about deps.edn - more low hanging fruit for a first contribution

Lone Ranger15:08:44

So I'm checking out the code in the docs.

(events/listen (gdom/getElement "button") EventType.CLICK
  (fn [e]
    (loader/load :bar
      (fn []
        ((resolve 'bar.core/woz))))))
so the loader/load and the loader/set-loaded! can be accomplished by any normal programmatic means, I take it, not just in response to click handlers? i.e, could also be a setTimeout, etc?


nothing specific about buttons

Lone Ranger15:08:06

beautiful. Now, last question (and apologize if this is obvious), even though the code is lazy loaded, all modules must be required via script tags, and these script tags are to be included with the initial HTML load (vs being dynamically written to the page?)

Lone Ranger15:08:52

I'm just trying to understand the division of labor between loader/load and what needs to be included in the initial HTML

Lone Ranger15:08:07

and then I'll run along and work on updating some docs 🙂


no all modules do not need to be loaded via script tags


only the ones that are needed for a real HTML page


for example you want a direct weblink to a specific part of the app


than that page only needs script tags for the modules needed to render that page


everything else can be loaded on demand

Lone Ranger16:08:48

aha..... great, thank you.

Lone Ranger15:08:01

I'll look into it


Is there a way to remove all unserializable stuff from a datastructure?


there's no built in way to do that


but you have stuff like clojure.walk to help - though it's not free


better to just not have that stuff in there in the first place

👍 4
Lone Ranger18:08:15

Efficiently? Probably not. What I've done is recurse with throw/catch. Could also probably do some spec stuff to coerce it


Why we should deeply want to know about shadow-cljs ? It’s not a destructive question. I really wanna know. :face_with_rolling_eyes:


Well, I have lots of reasons on why I use shadow-cljs. It really shines on building node.js apps


But there's also lots of other reasons: you can emit "browser code" that uses "node.js" requires (this means that you can generate Electron apps), you can use any React library (Reagent, Fulcro, OM, Re-Frame) to emit react-native code (with a REPL connected on Android!)


It's easier to configure how to "reload your app" after you save a file, its compilation is more "precise" than Figwheel (on my experience, Fighweel sometimes get lost while I'm working on it and compiles invalid code, don't know if newer versions fixes this), Shadow-CLJS also is able to bundle all your node libraries on a single .JS file (better for lambda apps or to deploy on a server because the final JS is smaller)

👍 4

These are amazing arguments.


Oh, I see now, why my descjopproject fail me while I’m trying to compile under advanced flag.


Yes, shadow also have some sensible defaults and it's easy to debug these things. For example, when something fails with advanced in Shadow you can compile it with --debug, so no need to remember the exact flags to debug the errors


@U3Y18N0UC, Any way to compile my existing Leiningen based Figwheel project with shadow-cljs ?


Well, it's easier to compile projects in shadow-cljs with the stand-alone shadow-cljs app that you can install with npm. But there's also the option to use lein too: just delete the dependencies for clojure and clojurescript, add the latest shadow-cljs dependency on lein (currently [thheller/shadow-cljs "2.8.52"]), and add the :target part of the shadow-cljs.edn file only.


The documentation of shadow-cljs is really good, so you can find more info here:


Have a nice day!


Or night, where I am is 7PM already 😄. Also, any trouble, please ping me on DM, I'll try to answer as soon as I can 🙂


I really love Shadow as well, for all the hassle it saves me. I’ve sort of standardized on using deps.edn, since it’s compatible with Datomic Ions, and feels in general like it’s the future. Having Shadow outsource deps management to deps.edn is really easy, you just,

{:dependencies []
 :deps {:aliases [:shadow-cljs]}}
for example, and then put a :shadow-cljs alias in deps.edn containing the desired dependencies.


(`:dependencies []` is obviously redundant, included above for illustrative purposes)


@U06B8J0AJ, I don’t get it. New Tools come with new pros and cons. Why we move out to the Clojure CLI ?


Oh no, I’m certainly not saying anyone should move anywhere. I’m saying that I have standardised on tools.deps, and I like it. You know, FWIW.


(and at work we using Datomic Ions, so deps.edn is mandatory)