"Fast Refresh"

[chaoky]

One of the nicest things about UI development in the Clojure and Javascript world is a feature that is usually called "fast refresh", and that is the ability to change the source code without losing the state on the page, this is specially useful when editing heavily nested components, removing the need to refresh the page and repeat every step to get into that component and see how it changed.

I would love to see some feature akin to that in laminar, this feature would also require some work on the bundler/devServer side.

https://www.snowpack.dev/concepts/hot-module-replacement
https://reactnative.dev/docs/fast-refresh
facebook/react#16604 (comment)

[raquo]

Hot module reloading / fast refresh is certainly a nice feature to have, but to be honest I have no idea how to even approach implementing it. Webpack's documentation on this appears inscrutable, although it could be just me, I'm not strong in tooling.

Intuitively, I suspect that it's either very hard or impossible to implement true and correct HMR for Laminar because

1. we don't use virtual DOM, and we have no hydration algorithm that can take actual DOM state, and update it to the state desired by Laminar
2. we have event streams, which have no concept of "last event" that can be fetched by the newly reloaded module

Some people use Laminar with live reload, i.e. have the whole page reload on code changes. I hear that Vite is a lot faster than Webpack for this.

Personally I don't even use live reload on my own Laminar code. I used to swear by HMR when I was coding in Javascript, because there isn't any other way to be sure what your code is doing, but with Scala's strict type system, 90% of the time it's the compiler telling me what's wrong, not the browser.

The one place where this approach does not work is CSS – pixel pushing requires many iterative visual checks pretty much by definition. So I do hot-reload CSS. Mine is generated by LESS CSS, and is a completely separate pipeline from Scala.js compilation / bundling, so changes are applied lightning fast.

I think realistically this plus live reloading the code is the best we can have, unless I am gravely mistaken about what's needed to implement HMR.

[chaoky]

feel like I could give working on this a shot,
this was a good read on how they did it for svelte
looking at the rollup api implementing this manually for a single component seem fairly straight forward

package Main

import com.raquo.laminar.api.L.{*, given}
import org.scalajs.dom
import scala.scalajs.js
import js.JSConverters.*
import scala.scalajs.js.annotation.*
import util.control.Exception.*
import com.raquo.laminar.nodes.ParentNode
import com.raquo.airstream.state.Var

object Element {
  @JSExportTopLevel("nameVar")
  val nameVar: Var[String] = {
    js.`import`.meta.hot.accept(() => {})
    Var(initial = "Wellm")
  }

  @JSExportTopLevel("element")
  val element: HtmlElement = {
    val elNode = div(
      label("Your name: "),
      input(
        onMountFocus,
        placeholder := "Enter your name here",
        onInput.mapToValue --> nameVar,
        value <-- nameVar
      ),
      span(
        "Hello, ",
        child.text <-- nameVar.signal.map(_.toUpperCase)
      )
    )

    js.`import`.meta.hot.accept((newModule: js.Dynamic) => {
      val newElNode: HtmlElement =
        newModule.$t_LMain_Element$__element.asInstanceOf

      elNode.maybeParent.map(p =>
        ParentNode.replaceChild(
          p,
          elNode,
          newElNode
        )
      )

      val newNameVar: Var[String] =
        newModule.$t_LMain_Element$__nameVar.asInstanceOf

      newNameVar.set(
        allCatch
          .opt(js.`import`.meta.hot.data.namedVar.asInstanceOf[String])
          .getOrElse("123")
      )

    })

    js.`import`.meta.hot.dispose(() => {
      js.`import`.meta.hot.data.namedVar = nameVar.now()
    })

    elNode
  }
}

object App {
  @JSExportTopLevel("mount")
  def mount(): Unit = {
    val appContainer = dom.document.querySelector("#app")
    render(appContainer, div(Element.element))
  }
}

it ended up taking me around 10 hours to navigate Laminar/Vite/Rollup/Scalajs documentation and build that example, but it works

[chaoky]

https://github.com/chaoky/proto-laminar-hmr

[chaoky]

surely keeping all state would be nice, but just replacing the modified components is 90% of the experience you get with React, since only the module you're editing will update and loose state

[raquo]

Whoa that's just RAD! Never thought I'd see this working with Laminar, even if a PoC.

My thoughts, looking at this, and having read the very good svelte HMR doc:

• I'm guessing one of the challenges would be to automate / abstract away the calls to js.import.meta.hot.accept/dispose, because having to write those out manually for every component would get more annoying than not having a hot reload.
• If I understand the idea of HMR bubbling correct, we don't even need to make literally every module HMR-capable, we can get away with only some of them being HMR-capable, and have HMR still work (but be less granular, perhaps requiring the reload of a parent / grandparent module if it's HMR-capable but the updated module isn't)
• Most of my own Laminar components accept inputs (including observables) and produce an Element as an output. Typically it's just an apply method inside an object. There are more complex components, but this one pattern is probably 90% of them for me. I wonder how you could hot-reload such a component – your PoC requires having a reference to an instance of an element in order to replace it in the DOM, but a simple function like A => Element does not keep track of its invocations, so it wouldn't be able to replace the Element instances that it previously returned.
• So perhaps for A => Element components, such a function needs to be wrapped in some kind of helper that keeps track of all invocations of that function (both the provided inputs and the resulting outputs), and then when the module code is updated, the inner function could be replaced, and all the elements it has previously output can be replaced with the new version too. Memory management will be a concern though, if there is no mechanism to discard no-longer-used instances. Perhaps something like JS WeakMap could help here.
• I guess the same logic could be applied to components that are classes – needing some helper to track the instances of the class, and rebuilding their Element outputs
• In general, it seems that one could define a set of component patterns that are HMR-able (such as the two examples above), and provide helpers for each pattern, and perhaps even write a macro that would detect such patterns and apply said helpers automatically. It won't be perfect but maybe it'll be good enough?

Am I thinking about this right?

[chaoky]

yea, having a macro for each component seems like the most straight forward method.

but something I was thinking about is, if every component had a name (like they do in React for debugging purposes), we could only keep track of a reference to the app's root node and loop over all children, replacing the ones where name matches with the new module's name, this would require only a vite plugin and a single macro, we could know what the function was called with by looking at it's importers source code

[chaoky]

I'm not familiar enough with laminar's API yet to come up with more cleaver solutions but I feel like there's one out there e.e