This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-27
Channels
- # announcements (10)
- # bangalore-clj (1)
- # beginners (130)
- # calva (8)
- # cider (66)
- # circleci (2)
- # clojure (197)
- # clojure-europe (2)
- # clojure-italy (8)
- # clojure-nl (5)
- # clojure-spec (14)
- # clojure-uk (35)
- # clojurescript (46)
- # code-reviews (5)
- # cursive (4)
- # datomic (88)
- # duct (1)
- # emacs (2)
- # figwheel-main (15)
- # fulcro (20)
- # graalvm (1)
- # graphql (3)
- # jackdaw (2)
- # leiningen (2)
- # off-topic (64)
- # pathom (53)
- # re-frame (52)
- # reagent (12)
- # reitit (43)
- # rewrite-clj (1)
- # shadow-cljs (38)
- # spacemacs (3)
- # sql (17)
- # tools-deps (6)
- # vim (30)
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)
?
it should be updated to talk about deps.edn - more low hanging fruit for a first contribution
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?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?)
I'm just trying to understand the division of labor between loader/load
and what needs to be included in the initial HTML
and then I'll run along and work on updating some docs 🙂
aha..... great, thank you.
I'll look into it
Is there a way to remove all unserializable stuff from a datastructure?
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)
Oh, I see now, why my descjop
project 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: https://shadow-cljs.github.io/docs/UsersGuide.html#Leiningen
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.@U06B8J0AJ, I don’t get it. New Tools come with new pros and cons. Why we move out to the Clojure CLI ?