Add onHydrated to JSX.Element

[btakita]

I brought this idea up on Discord, but want to move the discussion here to go more in depth & for better visibility.

To optimize hydration by removing double data caused by hydrating model signals, the DOM can be queried to hydrate the data.

Currently, createResource has onHydrated, which I am using to hydrate model signals which has reduced the initial html payload by megabytes in my current project.

const [client__d_, client__d__set] = createSignal()
const d_ = d__()
const html_id_ = createResource(()=>'unique_html_id', {
  onHydrated: ((_, { value })=>client__d__set(document.getElementById(value).getAttribute('d')))
})
return <path id={html_id_()} d={d_()} />
function d__() {
  if (!isServer) return client__d_
  // ssr data dependency sources
  return createMemo(()=>/* load data from ssr data sources */)
}

If onHydrated is added to JSX.Element, this boilerplate is reduced a bit...

const [client__d_, client__d__set] = createSignal()
const d_ = d__()
return <path d={d_()} onHydrated={el=>client__d__set(el.getAttribute('d'))} />
function d__() {
  if (!isServer) return client__d_
  // ssr data dependency sources
  return createMemo(()=>/* load data from ssr data sources */)
}

New primitive functionality can further reduce the boilerplate to support this optimization. Off the top of my head it could look something like:

const [d_, client__d__set] = createHydrator(()=>{
  // ssr data dependency sources
  return createMemo(()=>/* load data from ssr data sources */)
})
return <path d={d_()} onHydrated={el=>client__d__set(el.getAttribute('d'))} />

Note: If createResource were used to store & hydrate the d attribute, then the d value would have the double data issue, both in the HTML & in the createResource hydration. This optimization fixes the double data problem for the d attribute by querying the DOM to hydrate the model.

Note2: If // ssr data dependency sources were in the client code, it would be easy to accidentally trigger loading the full data model on the client side. It is more optimal to avoid loading the full data model & instead only hydrating the presented data on the client. This is why there is an isServer guard to only run // ssr data dependency sources on the server.