Show a message — core's one server action, and the shape a package's should copy.

Why this one is not a JS command

The other six move classes and visibility around, which the browser can do on its own. A message cannot be one of them: a flash lives on the socket, put_flash/3 writes it, the layout or the page renders it and lv:clear-flash dismisses it. There is no client-side way to add one, and inventing a second notification system beside the framework's would mean styling it twice and dismissing it twice.

So it takes the ordinary route a developer would have written by hand — JS.push/2 out, handle_event/3 and put_flash/3 back — and the words arrive in whatever flash component that site designed. MishkaCmsCore.Runtime.Compilers.LiveViewCompiler gives a page that carries the push the matching clause.

The handler is runtime code, deliberately

handler/1 names MishkaCmsCore.Runtime.PageMessage, not this module. What it names is compiled into every published page that uses the action, and a visitor's page has no business naming anything under MishkaCmsCore.Builder.*. A package's server action should point at its own runtime module for the same reason.