Component-Level Hydration

I’ve recently endeavoured into the spheres of elm. I am surprised of its practicality.

What does the concept of component-level hydration mean in the elm world? Possible, desirable, meaningful or useless?

I am thinking along the lines of Elixir Phoenix LiveView, explained in [4]. Related is this thread [3].


[1]

  • Page as a Component (our approach): Compose pages in JS, include each page as a cacheable <script> in the template, pass it data via props. This approach combines the best of both worlds, you get page composition in React, but also easy server-side rendering and caching of whole pages at a time. It’s also easier to manage the data flow when you don’t have separate react snippets, as all components are laid out hierarchically from one mount point downwards.
    - Slightly harder to mix & match template fragments with React components
  • More customizable build process than with Templated JS Snippets
  • Flexible, works equally well for non-React pages like Vue.js or Angular
  • Easier to manage data flow bc. of single JS entry point (esp. with redux)
  • 1 round-trip page-loads if script bundle is cached

[2]

[1] https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec
[2] https://hackernoon.com/reconciling-djangos-mvc-templates-with-react-components-3aa986cf510a
[3] Mobile app alternative (PWA) via ELM?
[4] https://www.youtube.com/watch?v=k4mSbCoBTPI

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.