Thread by @FabianCook

Today I got going an MVP VDOM implementation rolling, this is going to be a thread of details on what I'm up to, and why.

Let me introduce to you.. VGraph

If you're interested in code, here is some to checkout:

github.com/opennetwork/vd…
github.com/opennetwork/vn…
github.com/opennetwork/it…

Lots and lots of documentation to come for every one of these, the example folders give a slim glimpse of uses

I initially started out with iterable, the intention was to create a toolkit for lazy "streaming" of anything iterable, which in JavaScript means (not limited to) arrays, sets, maps, and generators

The iterable project is mostly stable, it's level 0 of VGraph, the core of it. An iterable is a fundamental list of values, you can access an iterable by creating an iterator and requesting the next value using the iterator till it is complete.

An iterable is a native feature of JavaScript, the iterable module is a toolkit to extend it.

The iterable module was a glimpse for me into the power of the language and what it has become.

The iterable module provides common "list" functions like reduce, map, filter, and adds some other iterable friendly functions like union, group, and drain.

It was a pretty good start down this rabbit hole

The original reason I had started exploring iterables was to implement an rdf dataset, which would allow me to represent a set of data nodes

You can see the code for what I got to here:

github.com/opennetwork/rd… & /rdf-dataset

So now I had a way to handle "basic" data, but wouldn't it be great if we could use something like functions, iterables, and jsx to construct these models directly? Well, that's where vnode came from, and was it's initial goal.

To fit this goal I needed something that:

- allowed updates to be consumed natively without anything more than the language
- allowed data to be represented without any additional tooling (jsx), but still supported it
- allowed multiple values per vnode
- async compatible

Some other things that were important:
- predictable state
- no or near zero magic
- time travel
- out of the box ready
- no or near zero framework knowledge to utilise / "just works"
- platform/target/process agnostic

The answer:
AsyncIterable<VNode>

What is this?
It's an async iterable (linked in reply), where each iteration of the iterable provides the next representation of a VNode as a promise

How do I consume it?
for await (const vnode of instance) { /* things here */ }

What a VNode?
Any object or function with the property "reference" with a string, number, symbol, or boolean value

github.com/opennetwork/vn…

The above fundamental details propagate across the rest of the project.

The vnode module is completely annotated within source, I wanted to ensure my full intentions with every line was explained, giving a solid foundation for future improvements

Representing a single node, with no dependencies is straightforward, introducing children, is a next step. It took me a few iterations, but as with the rest of the codebase, the simpler solutions ended up being the winner.

Children in vnode are represented as
AsyncIterable<AsyncIterable<VNode>>

Why two??
Because now we are representing in each iteration a new group of children

How do I consume it?
for await (const children of vnode.children) { for await (const child of children) {}}

Now we have the concept of children, another core concept we can tackle: Fragment

What's a fragment? A group of vnode updates

From the source: "A FragmentVNode should be ignored and the children should be used in its place"

Now with these few concepts, we have almost the entirety of the vnode module. There is a bunch more here that I could go on about but I'll leave vnode for now...

Once I had vnode working, I moved on to vdom, after a few tries I got something pretty good working, it's not ready for prime time, but I believe I have the fundamentals down, and it's at the stage now where I really would love some input

At this stage I'm able to render elements & text, which is a good start, and we can build from there, but haven't yet gone further than mounting these nodes. We're at the moment where key decisions can be made easier without back tracking on past ideas, so here we are

If you're wanting to help directly on this project, great! I need as much help as I can get, head over to the GitHub links, ask questions, and go from there, there is lots to do!

I'm looking for specific help right now with:
- Platform experience, e.g. what am I going to trip on in the DOM
- Developer experience, e.g. how should I expose the native platform to the developer
- User experience, e.g. how can I best explain what we have

I am extremely happy with the current state of the project, and I wouldn't have been able to get to this point without all the help and conversations I've had with so many people, so thank you to all those kind souls.

I'm happy to answer any and all questions on this!

As a small note, I don't believe they're at the release stage, but they're definitely on their way.

I'll be referencing this project as VGraph as a whole, and will soon host details of it at VGraph.dev

If you read through all this, thank you. I'm excited to see where this project goes, and will be forever grateful for any and all help to get it there.

developer.mozilla.org/en-US/docs/Web…