stuartish
commented
2 years ago I suspect LiveView is nearing its v1.0 in the next couple years. The next few iterations, especially on templating language, seem like a major part of getting there now that the fundamental functionality is pretty solid.
I'm in the process of upgrading liveview on platform to 0.17.x, which introduces "slots" as yet another syntax. One which is amenable to harmonium's intent with even less typing than it already achieves.
Because platform depends on harmonium (and adminable, which has the same issue fwiw) it's simpler to create a harmonium release (with trivial code changes) that is "compatible" with liveview. It won't be efficient, but imho that really doesn't matter. Runtime efficiency of elixir code is the least concern of every one of our projects I'm aware of; rerenders are comparatively rare. It's not like we're making lots of games with high framerate requirements.
Furthermore, in light of extremely powerful liveview features like 0-hassle file uploads, as I've said before--we have few reasons to ever develop a phoenix application without liveview. Accordingly, my opinion is that phoenix_harmonium 2.x be sunset with the expectation that projects which rely on it and are not upgrading liveview will not update.
Whether we create 3.0 or not should be considered with understanding that it is more-or-less a rewrite. @CheetoMao any reckoning of how much time harmonium's class injection functions save is very welcome in making that comparison of expense.
The current helpers use content tags extensively, and do not use the new
HEEx. We should refactor these helpers to use the new phoenix component module blocks syntax so we can support phoenix >= 1.6 and perform better within liveviewshttps://hexdocs.pm/phoenix_live_view/Phoenix.Component.html#module-blocks