This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-15
Channels
- # announcements (51)
- # beginners (65)
- # calva (44)
- # cider (6)
- # clara (3)
- # clj-kondo (30)
- # cljsrn (5)
- # clojure (63)
- # clojure-australia (7)
- # clojure-dev (7)
- # clojure-europe (43)
- # clojure-gamedev (1)
- # clojure-nl (6)
- # clojure-uk (7)
- # clojurescript (51)
- # conjure (1)
- # cursive (9)
- # datascript (16)
- # datomic (14)
- # depstar (20)
- # events (1)
- # exercism (17)
- # figwheel-main (6)
- # fulcro (9)
- # graphql (3)
- # gratitude (2)
- # honeysql (4)
- # jobs (7)
- # leiningen (3)
- # lsp (107)
- # meander (7)
- # minecraft (3)
- # off-topic (16)
- # other-languages (4)
- # pathom (4)
- # pedestal (26)
- # practicalli (4)
- # re-frame (3)
- # reitit (7)
- # remote-jobs (1)
- # shadow-cljs (26)
- # tools-deps (67)
- # vim (19)
- # vscode (1)
@thheller we (@rosado & i) did an experiment - we created an RN build with a chunk, and added logging to the chunk .js wrapper so that we could see when the file is loaded. we js/require
d the chunk on a click in the app, and confirmed that the chunk .js file was indeed loaded dynamically
@mccraigmccraig thanks for the feedback. good to know 🙂
very good for us - if we couldn't get a working cljs code-splitting story with react-native then we would have had to give up on cljs 🙀
we're porting our app from cordova to react-native now, and building code-splitting in from the beginning of the port. analysis we did on the cordova app suggested we could save about 60% of the js load time by loading on demand. it will not make that much difference for a user with an iphone 13 (time-to-interactive <2s), but will make a big difference to anyone on an underpowered android from a few years ago (time-to-interactive >10s)
hm yeah. only other project I know using :chunks
for RN is the status-im stuff. always good to have some more data on hand for this stuff 🙂
RN is all quite new to me, but i had a look around the shadow source... it looks like :chunks
is sugar over :modules
- and the js/require
stuff in RN itself is all pretty vanilla - so altogether there doesn't seem to be anything scary or magical about the splitting or loading mechanisms, which definitely gave me some comfort
yeah. I only looked at the RN JS examples on how to do lazy loading. so I knew what kind of output it needs and just made shadow-cljs create that 😛
never built an actual RN app myself but seemed straightforward enough to implement so I did
basically everything in shadow-cljs is based on :modules
(or now called :chunks
) so it was quite easy
closure compiler renamed everything from modules to chunks so I just started the RN stuff with :chunks
directly
ahh, that's why :chunks
- i did wonder
the name makes more sense too. modules is quite overused and unclear what it actually means
yeah, chunks is clearer
RN has its own code-splitting mechanism called RAM Bundles (yet another word for it)... it did take me a while to realise that we could ignore that, because once the code-splitting is done, it's just js/require
yeah I was never sure how to get the actual lazy loading part since js/require looks sync
um i think js/require
is sync - doesn't matter to me though - tiny (mostly not noticeable, unless you've got one of those underpowered old 'droids, in which case you are used to them) pauses throughout a session vs big pause at the start of a session
if you want some additional docs on RN config for shadow, i'm happy to do a PR or whatever, once we're properly up and running
always welcome to get more docs on the topic. I don't use RN myself so I let a linger a little too much 😛
I have a question that I probably know the answer to but curious to get others thoughts, related to code splitting: say I have a library where I want to dynamically load some code. e.g. something like re-frame-10x or another dev tool that is used to inspect the running state of the app. I'd like it to be available in production, but not affect the size of the main bundle of the app. could there be a way in the future to "provide a chunk" as a library? the alternative here of course is to instruct users how to configure the chunk themselves, which seems like a task many wouldn't want to bother with but obviously works today