MishkaCmsCore. Runtime. Handlers. RuntimeOrchestrator
(Mishka CMS Core v0.0.1)
Copy Markdown
View Source
Central rebuild coordinator for the runtime pipeline.
Single-resource edits flow through SendToOban → RuntimeCompilerWorker,
which already debounces/dedups per-site asset jobs. This module owns the
OTHER path: a bulk write (e.g. the UI-kit installer inserts hundreds of
rows in one transaction with defer_runtime: true) that must rebuild the
runtime once for the final result instead of per row.
sync_after_bulk/1 rebuilds from the DB using the same steps boot uses:
- component templates + modules (
BootHandler.compile_components/0), and for each component row the batch wrote, a module a render had already built is built again from it (RuntimeCompilerWorker.refresh_after_bulk/1) - JS-hook templates (
BootHandler.create_js_hooks_template/0) - stylesheet load (
BootHandler.load_stylesheets/0) - for a global change: drop + rebuild the shared base once
- fan out per-site asset jobs (unique + debounced)
Step 4 precedes 5 so every site recompiles against a fresh shared base
(avoids the stale/partial-base bug). Asset jobs are deduped in
BootHandler.asset_job/4, so the fan-out can never storm.
No-op under config :mishka_cms_core, env_test?: true so tests stay fast and
don't depend on a populated AssetsState.
See MishkaCmsCore.Runtime.Handlers.BootHandler and
MishkaCmsCore.Runtime.Compilers.TailwindCompiler.
Summary
Functions
Rebuild the runtime once after a deferred bulk write.
Functions
@spec sync_after_bulk(keyword()) :: :ok
Rebuild the runtime once after a deferred bulk write.
Options
:scope—:global(default) rebuilds the shared base and fans out to every active site;{:site, site_id}scopes the rebuild to one site.:kinds— which resource kinds were touched (default[:component, :js_hook, :stylesheet]); limits which build steps run.:components— the component rows the batch wrote (default[]). Each one's module is brought up to date as a single save of it would bring it — seeRuntimeCompilerWorker.refresh_after_bulk/1.