Anyone have any best practices on conditionally including source files at build time? We pass in an instance type, and we would like to load a src file based on that instance type, like for two instance types ["car" "boat"] if we are building a car-type, we'd like data.config.car to be loaded, conversely data.config.boat.. right now they live in a big map where the top-most key is the instance type, but we'd like to break them out to shake the bundle size, because the config maps can get pretty large. Any clues appreciated 🙂 Sorry if its not nearly enough specifics, can try and be more specific if needed. edit: current build is via babashka -> shadow-cljs
> We pass in an instance type Pass to what? And how? Is that information available at compile time, with a guarantee that a new instance type won't appear?
We pass the instance type to babashka like: bb run-local --instance-type "car" --stage "dev" this does a few things, including putting the instance type and stage as header metadata in the index, from whence its scooped up by re-frame on load and stored in app-db.. the config is 100% available at compile time and no need for it to mutate once built,
I'd do it via separate shadow-cljs builds then.
You can also do all the other mentioned stuff that way, too. Just have some :closure-defines in each build and use those values in the initial value of app-db.
Thanks! I was looking at the build targets but wasn't sure if that was the right feature to pint this on
No-no, not build targets. Just builds. (Just in case.)
Oh good catch, I had conflated the two in my head since out of the box there's basically 1 build in there per type, but yes, Just builds!
if its just data I'd load them as .edn files and not compile them at all
otherwise you could do code splitting and use a module per "type" https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html
alternatively multiple builds is also fine, if its all completely static
We have a similar usecase and we use the compiler option :reader-features. With a common cljc file we require/register functions in specific namespaces with that. Flexible, managed by Clojure itself so it does not rely on later optimization, and we also didn't want to separate the code in different builds (for few reasons). Note that we use the shadow cljs CLI with the --config-merge to dynamically set this (and it's not necessarly one reader-macro for each instance).