Idea: Dismantle, repurpose, transfer, reuse?

[jorgebucaran]

Instead of reusing Ultradom in Hyperapp (which is totally possible, but a bit awkward in my opinion) what if Hyperapp exported its patch function instead?

import { h, patch } from "hyperapp"

// Use h & patch as you normally would in Ultradom.

Thanks to tree-shaking, dependents of Ultradom will not need to include Hyperapp's state management portion. 🎉

My intention is to reuse code and remove the burden of maintaining both Hyperapp and Ultradom when their respective virtual DOM implementations are virtually (pun intended) the same.

---

So, what would happen to Ultradom? Good question. I don't know. Perhaps I could use it for experiments, a more sophisticated virtual DOM implementation, a new framework, library, etc.

What do you think?

[frenzzy]

That is exactly what I proposed in https://github.com/hyperapp/hyperapp/issues/641#issuecomment-371089209

It opens new opportunities for userland, for example will be be possible to implement async rendering (around which now is a hype in the React.js community) or priority rendering (hello fiber) for hyperapp without overhead - no need to additionally use ultradom which just adds extra bytes.

[jorgebucaran]

@frenzzy Are you it's exactly the same? I am only talking about exposing patch to userland — not to expose the state management part.

I mean: it's either stateman+virtualdom or virtualdom, but not stateman alone. 😉

[frenzzy]

State management is already available via app function. Proof of concept: https://github.com/Swizz/hyperapp-term-poc So, I also think it is not necessary to expose something more. Just h, app and patch is enough.

[rbiggs]

Enabling the export of patch from Hyperapp would eliminate the reason for Ultradom. One less library to maintain. :-)

[dancespiele]

I'm agree with this if I will be able to use hyperapp with patch exactly how I'm using with Ultradom, without actions. I mean hyperapp with the exacly patch than Ultradom.

[mindplay-dk]

If that's possible, why not just extract the patch-function and call it ultradom? Just move the code to that package?

I've always said, the patch-function is a library function - what's actually Hyperapp is just a thin framework using that function. The fact that you'd be able to install Hyperapp and use tree-shaking to remove the framework practically proves my point.

The main reason not to package a library in a framework in the first place, is just simply versioning - any breaking change to Hyperapp would be versioned as a breaking change to those using only the library, whether there's a breaking change to the library or not. The framework depends on the library. Not the other way around.

[jorgebucaran]

@mindplay-dk That's the plan no?

[mindplay-dk]

That's the plan no?

It’s not what you described though?

I’m arguing in favor of two packages. Whether the patch library package is named ultradom or hyperapp-dom or something else is besides the point to me :-)

[jorgebucaran]

So, you are basically in favor of either keeping things the way they are or using ultradom as a dependency in Hyperapp.

I like the first, but not so much the latter. My current favorite is simply exporting patch from Hyperapp without much breakage and reuse this repo for a more feature-oriented vdom, something I am code-calling fringe for a while.

[jorgebucaran]

https://github.com/jorgebucaran/ultradom/releases/tag/3.0.0