Sinuous + MobX integration

[luwes]

Would be really cool to see an integration with MobX.
This can be done via the internal API Sinuous exposes https://github.com/luwes/sinuous#internal-api

As of 0.27.4 the internal API should be used to make Sinuous work with a 3rd party reactive library like Mobx. This can be done by overriding subscribe, root, sample and cleanup.

[creativenull]

Hey 👋! Mind if I give this a try? I'm new to sinuous but I do know a bit of MobX

[luwes]

hey Arnold 👋, of course feel free to try it out. I'm happy to help if you have any questions. Thanks

[creativenull]

Thanks! Yes, I do have questions as to how I could go about writing this 😁. I'm new to this so forgive me if I get the terminologies wrong.

I read thru the docs and the api that you linked. Overall, I was able to get the mobx state to update when I ran it like this

import { html } from 'sinuous';
import { autorun } from 'mobx';
import { state } from './store'

function List() {
  autorun(() => console.log(state.items));

  return html`
    <div>${state.items}</div>
    <button onclick=${ () => {state.items = 'make pancakes, get cheese'} }>Update</button>
  `;
}

export default List;

However, this will only work on devtools console. I can see that I can change maybe the api.subscribe or api.h where the rendering would take place, but I'm not too sure if that would be the right place. So I'm trying to see where can I find the docs on the rendering and also be able to see how your sinuous/observable library does the re-render?

[luwes]

I added a basic working example here for the autorun patch which translates to Sinuous's subscribe I think.
https://codesandbox.io/s/sinuous-mobx-wzhlx?file=/src/sinuous-mobx.js

The other important api's that need to be converted are root, sample and cleanup, I'm a little worried if they are even accessible in Mobx which would cause a problem 😅

(possibly @mweststrate can quickly point it out? 🙇)

One thing to keep in mind is that Sinuous doesn't do a traditional re-render where it executes the whole List function again. It only re-runs the closures in the template.

  <div>${() => state.items}</div>
  <div>${() => boxExample.get()}</div>

That's why there needs to be a closure or function reference. I had hoped boxExample.get would be sufficient <div>${boxExample.get}</div> but it seems it's not detected as a function ref 🤷 .

[creativenull]

After reading your response, it got me thinking.. what if autorun could become the renderer? Which ended to me writing this hacky code, at the root level...

import { html } from 'sinuous'
import { autorun } from 'mobx'
import App from './App'

function renderApp (id) {
  const mainApp = html`
    <${App} />
  `
  document.getElementById(id).replaceChildren(mainApp)
}

document.addEventListener('DOMContentLoaded', () => {
  autorun(() => {
    renderApp('app')
  })
})

Where it will re-render the whole DOM if any of the children modify a mobx state, but I don't think this would be the right way, just find this a bit interesting.

Let me read thru the docs for root, sample and cleanup. I know that cleanup would be needed to run the function returned from autorun/reaction (from Mobx) and subscribe should trigger the changes the way you explained. But I'm not sure what root and sample would help in this case. Could you elaborate a little bit on this? Will it really be needed by mobx in terms of playing nicely with sinuous?

[tsugabloom]

There's a lot of push in Sinuous and friends to have fine-grained updates since web frameworks try to touch the DOM as little as possible.

Some take the VDOM diff approach, like React or Choo.js, which allows developers to write code that looks like it updates everything on every change, but still doesn't touch the DOM unless it has to.

Frameworks that don't have a VDOM (like Sinuous, Solid, Surplus, Svelte) use the fine-grained update approach. There is no diffing. Instead, these frameworks want to know ahead of time the smallest regions of DOM to update and focus only on those.

What you're proposing needs a different style of framework, since it would be very expensive in this model since re-rendering everything would touch all the DOM.

[mweststrate]

If think what you want to leverage MobX, the thing you want to achieve is that MobX runs the reactive closures in autorun, not the entire component (that is what it does in React, but the beauty of the sinuous model is that isn't needed)

[creativenull]

@mweststrate that is true, I also don't see the need to try to have a "render" if mobx just runs in reactive closures.

I was able to tweak @luwes code a bit and created a wrapper that can be used as a subscribe function to use within any component. How this works, is that the subscribe functionality will register it as a mobx autorun at first. If you call the subscribe and pass two function arguments to it, this it will call a mobx reaction. Eventually, passing a disposer function to cleanup in case it's needed. Please see the link:

https://jsfiddle.net/fmdb48kL/

While this works, the problem I encountered was that autorun will be called twice. I'm guessing it calls the first time on the render and then again after a component register? I could be wrong, but other than that it seems to work as intended.