Contrib.social

Meeting notes: May 20th 2024 - Isomorphic rendering

Open on Drupal.org →
Created on 22 May 2024, about 1 month ago
Updated 25 June 2024, about 16 hours ago

Experience builder meeting

Attendees EclipseGc, bnjmnm, e0ipso, nod_, tim.plunkett, pdureau, larowlan

  • Broad goal: Attempt be able to dynamically update components client side when working with the experience builder without needing an AJAX call/round trip. Achieve this by some form of Isomorphic rendering of templates on both frontend (FE) and backend (BE)
  • Meeting purpose: Ensure we're not competing with each other in our experiments in this space.
  • Pierre demoed dilla.io - an approach for isomorphic rendering using WASM. Twig templates are converted to minijinja via build (make) task. Then compiled into WASM. PHP loads the WASM and uses it for rendering. The browser can also load the WASM and use it for rendering too. The WASM includes handling of other non-template aspects of Drupal rendering such as handling libraries.
    • Pros: Genuine isomorphic result between FE and BE
    • Cons: Requires PHP compiled with WASM support which isn't the
      default. Requires build steps
  • Lee demoed building a component abstract syntax tree from Twig using the Twig compiler and a Lexer that uses masterminds/html5
    • Pros: Generating an AST allows for other options outside React.
      Renders as plain JS so no build step. Can leverage existing Twig
      compiler caching to disk.
    • Cons: Still a lot of work to do, there will be some Twig functions
      where adding support will be difficult (or perhaps impossible)
  • Ben demoed the React JSX theme engine which makes use of React and hyperscriptify to render JSX in Drupal
    • Pros: Can intersperse Twig with React. Understands Form API.
      Compatible with state management like Redux.
    • Cons: Requires rewriting Twig components as React (JSX) and an
      equivalent JSON file detailing prop. Client side rendering only
      (Drupal emits a template tag only). Needs a transpiling step when
      editing JSX files.
  • Tim demoed Alex's Svelte AST approach where Svelte code can be converted to Twig and JSX
    • Pros: Write in one language, output as multiple targets. Safer to
      let site builders/editors author in Svelte than Twig (possible
      security/stability issues)
    • Cons: Need to rewrite all twig files in Svelte first. May need a
      server side JS runtime (need to confirm). React is output as JSX
      (not JS) so needs transpile step (Babel).

Meeting conclusions:

  • It feels like all of the approaches have synergies and aren't directly
    competing. E.g. If Lee's AST were finished then Ben's approach could
    leverage it to do the Twig to JSX conversion or Alex's approach could
    use it via a console command to migrate from Twig to Svelte.
  • The WASM approach feels the most technically superior but (by Pierre's
    admission) is not a solution for right now. When PHP adds native support
    for WASM this future will arrive.

Other notes:

Pierre noted we will likely need to limit what Twig can be used in SDC components because some twig functions rely on system state rather than pure component state - e.g. things like format_date make use of config entities.

🌱 Plan
Status

Fixed

Component

Meetings

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024