VanJS Component API

[yahia-berashish]

Me and @Hunter-Gu were trying to implement a Context API for state management, he found a way by creating a simple component implementation that managed to get the Context API working, but I recommend separating that functionality (with slight modifications) to a different package that can be used as a base for future packages (like the Context API).

A package (something like vanjs-components) that would provide a simple component tree implementation (because VanJS doesn't have components) and possibly a simple lightweight virtual DOM implementation too, would be great for keeping VanJS itself (core and official extension(s)) lightweight and simple while providing additional more advanced functionality for more sophisticated implementations and API.

This is the sandbox link for the implementation.
Would like to hear your opinion.

[Tao-VanJS]

Hi,

We do have a component library for VanJS: https://github.com/vanjs-org/van/tree/main/components. Initially it was a collection of UI components, recently we have a utility component Await there thanks to @Hunter-Gu's contribution. I think it might be appropriate to put the Context component there.

[Tao-VanJS]

For the context utility, can we expose functions with names like Context and WithContext in the public API of VanUI?

[yahia-berashish]

Maybe, but isn't the context separate from VanUI?
Most of what the context does isn't related to components/UI.
I still think implementing a lightweight component tree (via a new package) can be a good choice for the Context API to be built on top of.

[Tao-VanJS]

 I think Context can be considered as a special "utility" component. In the example you provided:

  return div(
    ThemeContext.Provider({ value: "light" }, () =>
      ThemedComponent({ hello: "World" }),
    ),
    ThemeContext.Provider({ value: "dark" }, () =>
      ThemedComponent({ hello: "Universe" }),
    ),
  );

The ThemeContext.Provider is part of the DOM tree, which makes it similar to ordinary UI components.

Alternatively, if you really think context should have its own package, you can consider to add it to the addons of VanJS.

[Hunter-Gu]

Let me clarify.

The code example in your comment can work for most cases, but it can't work correctly if component is rendered conditionally. This is the example, and you can aslo find our discussions here .

The key of Context API is we have to know the Provider in ancestor tree, but there is no component representation in VanJS internal.

And I also tried to get the tree from DOM, but the DOM will be rendered/updated asynchronously, so the component will always rendered with default value firstly. You can find the example here, you can find our discussions here .

Let me explain what is VanJS Component API now.

VanJS Component API is a package to build component tree for VanJS, component can have the ability to know the component tree. It will not only work for Context API, but also for lifecycle APIs, dev tool and other modern features.

So VanJS Component API is not a component, it is an enhancer for VanJS in a degree.

I think the biggest difference between VanJS and other frameworks(React, Vue, etc.) is component-oriented, just like we discussed in #130.

[Tao-VanJS]

I see. Thanks @yahia-berashish and @Hunter-Gu for your insights!

I trust your judgement. And I think this can be published as a separate add-on in addons directory. In the README.md of the VanJS GitHub repo, there is a section that introduces all the 3rd-party add-ons for better discoverability: https://github.com/vanjs-org/van#community-add-ons. I can consider to add the section in https://vanjs.org/ home page as well.

[yahia-berashish]

Hello @Hunter-Gu @Tao-VanJS
This is a very simple implementation of a component tree:
https://github.com/yahia-berashish/vanjs-components.git

It still has an issue of not supporting conditionally rendering elements and components and adding them to the component tree, but I'm sure it can be fixed.

[Hunter-Gu]

Personally I think it is a little complex.

C (create component) return a VanComponent instance rather ChildDom, so you have to patch van.tags by VanElement to make sure it can render VanComponent correctly.

Also, it makes the VanComponent contagious, which means the parent of VanComponent must be an VanElement.

I wonder if user want to adopt into VanComponent partially (maybe a group of components, like form group) for existing project.

I think this is simpler:

function createComponent<T extends Props>(
  fn: FC<T>,
  { name }: { name?: string } = {}
) {
  const Component = (props: T, children?: ChildDom) => {
    const current = getCurrentNode();
    const node: Node = {
      name: name || fn.name || 'Anonymous',
      isRoot: !current,
      children: [],
      parent: null,
    };

    if (current) {
      current.children.push(node);
      node.parent = current;
    }

    setCurrentNode(node);

    const result = fn(props, children);

    setCurrentNode(node.parent);

    return result;
  };

  return Component;
}

sandbox

What do you think of this implementation?

[yahia-berashish]

Yes, it is complex, but I think it doesn't break the point of vanjs, it is very lightweight, and it is a separate addon that more complex projects could use, and that would provide an API for more complex packages like a context API to rely upon.
And also it can be used with regular vanjs elements via the .toHTML() and .toDOM() methods of the component and the element. Maybe they could be unified to .toDOM() to make converting both components and elements easier.
The developer can use normal HTML elements provided byvanjs-core and encapsulate them inside functions, but they will be treated as children of their parent VanElement rather than elements, thinking about it now, maybe creating an element type was overkill, and a component class would probably be enough, so ya, you are right about that.

About the implementation you provided, I don't seem to fully understand it, how does it (and does it) store a component tree?
I would be happy to use a simpler implementation if you could explain it!

[Hunter-Gu]

In my opinion, for component APIs like Context, lifecycles, etc, the key point is to get current component node. So I export a public api to support get current node, a component can get it's parent and children with this.

The currentNode is just like a pointer, it point to the current rendering component.

I implement the Context API with this, you can take a look on sandbox