Comment like control and traversal

[bigopon]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
There seems to be no control that can act like a comment in html, where presence in the DOM does not affect the UI. Could it be a box with width: 0, height: 0 or something?

Describe alternatives you've considered
I've not tried any.

Additional context

• It would also be nice if UiControl and UiEntryBase could be marked as abstract class, as I don't think we can pass the right native handle to their contructors? Or if right native handle could be pointed out, that would be awesome.
• There seems to be lack doc / method around DOM traversal, how would one supposed to traverse in Libui-node DOM?

[parro-it]

There seems to be no control that can act like a comment in html, where presence in the DOM does not affect the UI. Could it be a box with width: 0, height: 0 or something?

I'm not sure I understand the purpose of a native control that does not affect the UI in any way. Could you expand on what exactly is your need?

It would also be nice if UiControl and UiEntryBase could be marked as abstract class, as I don't think we can pass the right native handle to their contructors? Or if right native handle could be pointed out, that would be awesome.

Yes, I agree. How are you exactly thinking to mark them? In docs?

There seems to be lack doc / method around DOM traversal, how would one supposed to traverse in Libui-node DOM?

Yes, libui is missing an unified behaviour within the various kind of containers.
You can see here: andlabs/libui#328 and on issues linked there for some discussion.

Anyway, we are tracking all containers children by ourselves in the binding, primarily to allow us to correctly free memory. You can see the c source here: https://github.com/parro-it/libui-napi/blob/master/src/control.c#L73

If you need them, we can expose all or some of these functions to js to allow for a proper traversal of the native widgets.

[bigopon]

How are you exactly thinking to mark them? In docs?

I think annotating the class with @abstract would be sufficient. It could also use some comment.

/**
 * @abstract
 * A base class for text related entries.
 * @extends UiControl
 */
class UiEntryBase extends UiControl {
	constructor(handle) {
		super(handle);
	}
}

If you need them, we can expose all or some of these functions to js to allow for a proper traversal of the native widgets.

That'd be awesome. I think that feature will eventually make it into libui anyway, maybe do it here first and then later use it from upstream?

I'm not sure I understand the purpose of a native control that does not affect the UI in any way. Could you expand on what exactly is your need?

My need is to mark a location in the ui DOM, to be able to insert / remove for different scenario. In Aurelia, there are template controller custom attributes, which compiles their own template and insert corresponding template instance to the location where they are defined. Following is an example:

<template>
  <ui-form>
    <ui-entry text.bind="firstName" />
    <ui-checkbox checked.bind="hasLastName" />
    <ui-entry if.bind="hasLastName" text.bind="lastName" />
  </ui-form>
</template>

The 2nd <ui-entry/> will be converted in to a "comment" or a marker, to mark where its template instance should be rendered to (the template of it is <ui-entry text.bind="lastName" />)

Without a clear way to do this, I may fall back to a virtual dom layer, that will act as a proxy to forward property values to libui-node instances, while preserving their template location. However, this is not great and generally not how Aurelia works: directly against native object instead going through a virtual dom layer.

[bigopon]

The need for comment was also the reason I found out UiControl should be abstract

[parro-it]

Maybe you can use an invisible control of the correct kind?

libui-napi/js/ui-control.js

Line 44 in 51e253a

set visible(value) {

The visible property is available on each control type...

[bigopon]

Yes. How should I construct one? I couldn't find anything similar to the following 😬

new libui.UiControl(libui.createDumbControl())

[mischnic]

const dummy = new libui.UiLabel("some data");
dummy.visible = false;

You shouldn't even be able to get the libui.UiControl class (like in your code snippet).

[bigopon]

Nice. Thanks for pointing that out @mischnic

[bigopon]

@parro-it @mischnic Thanks for your help, I was able to put together a basic example of integration with libui node with Aurelia. You can see it in this PR aurelia/aurelia#327

While doing this, I wonder what is typescript typing story like? Is it still waiting for full typescript conversion as seen in a PR in libui node? In case you want to keep everything in JS and publish a typings file only, here is my initial work on it to be able to do the integration easily https://github.com/aurelia/aurelia/blob/e87b9728aa109af5ec023f277f3f342fec37a829/packages/runtime/src/libui-dom.d.ts

Let me know if it's desirable, I can submit a PR.

[parro-it]

Is it still waiting for full typescript conversion as seen in a PR in libui node?

Yes, there are no further progress on that side, a PR would be greatly appreciated, thatnk you!

[parro-it]

It would also be nice if UiControl and UiEntryBase could be marked as abstract class, as I don't think we can pass the right native handle to their contructors? Or if right native handle could be pointed out, that would be awesome.

I created a separate issue to track this: #62

There seems to be lack doc / method around DOM traversal, how would one supposed to traverse in Libui-node DOM?

Could you better explain in detail what are your need?

As I said, we are currently book-keeping all container children in a c linked list, in order to correctly free them when needed.
Using that, we can expose some public methods in the API that allow to easily iterate all children of a container, and also access them by index.

But, as I understand from your snippet:

<ui-entry if.bind="hasLastName" text.bind="lastName" />

Removal and addition at a specific index is more difficult to implement, because not all libui container widgets does not allow you to do this.

[bigopon]

@parro-it Indeed it's hard to do it like in that template, because there is no common base class with container-like methods for all libui-node widgets. I think there are two ways to solve this:

• libui-node adopts a tree structure: all widgets derive from a based class with container like methods. i.e: UiNode. Every widget is a container but only accept a certain child types. I'm not sure how the API is gonna look like.
• leave it up to higher level frameworks to define their own tree structure

I'm very tempted to say libui-node should do the former, because it benefits all the frameworks, but I understand that it's more work, so I'm also happy to just do the later. It's needed for other platform integration anyway.

Thoughts? @parro-it @mischnic

[parro-it]

libui-node adopts a tree structure: all widgets derive from a based class with container like methods. i.e: UiNode. Every widget is a container but only accept a certain child types. I'm not sure how the API is gonna look like.

I already started to implement this. The idea is that every widget will have a children properties. This property it's an Iterable over children of the widget, and also can retrieve children by index.

Access by index will be probably not performant, because internally we are using a linked list, iteration should be preferred.

[bigopon]

I already started to implement this. The idea is that every widget will have a children properties.

That sounds awesome. Looking towards it!

Re: perf: cool 👍

I don't see myself iterating / performing array operations a lot usually. And also higher level frameworks normally do a ton of work to optimize this scenario, so if you give a mean to iterate fast, I think it's good.