Component-Level Hydration

Learn
1

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_5UGQKpjUAJAJMUtOgbJc5A
1_5UGQKpjUAJAJMUtOgbJc5A1212×428 86.7 KB

[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] Maybe you don’t need that SPA. There’s an article by Tom MacWright… | by Michael Rawlings | Medium
[2] Reconciling Backend Templates with Frontend Components | HackerNoon
[3] Mobile app alternative (PWA) via ELM? - #8 by pdamoc
[4] https://www.youtube.com/watch?v=k4mSbCoBTPI

2

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