Separate static and dynamic attributes?

[nandoflorestan]

Hello, domino looks awesome, thank you for writing it.

This is a question. The interactive-dom library, which inspired domino, has an API with a little optimization, in which user code provides static HTML attributes in a separate argument from the dynamic attributes.

I haven't found the same thing in domino; am I missing it? If not, why doesn't domino have that concept?

(I hope the question is clear enough.)

Further, is writing documentation for this library already planned?

Kind regards,
Nando

[isoos]

@nandoflorestan: are you referring to attributes that are known to be not changing and treated differently than the rest?

Do you know any benchmark that shows measurable benefits of such attributes? As far as I see, they add a nontrivial complexity for the dom reuse code, and I haven't seen the need for it yet, but if somebody implements them and they do provide benefits, I will happily merge them.

Further, is writing documentation for this library already planned?

PRs and/or questions are accepted :) I haven't set aside dedicated time for this, but if there is interest, I can be pushed to do it :)

[nandoflorestan]

Yes, that is what I am referring to. User code is the one that knows "this application won't need to change these attributes", so it provides you with these static attributes in a separate argument. The separation between static and dynamic attributes is done by user code, not by you. And then you create them the first time and ignore them when updating the DOM.

I don't understand why you say the feature would add implementation complexity – I would assume none. The API gets a tiny bit more complex (one more argument, probably optional). The types for static and dynamic attributes would be the same, no new types to write. The only thing is, static attributes are skipped on updates. This obviously leads to some optimization, but it's true, I don't know how much. Still, it's something I would like to use.

If I were reimplementing a library that has been maintained by Google for, I don't know, 8 years?, I would think real hard about any changes. In this case, you removed a feature, but I don't understand your reasoning.

You say you would document the library if there were interest. But as you know, the reverse is also true: people are much more interested in a library when it is documented. Maybe just start by writing some examples, covering as much ground as possible, but without taking the trouble of documenting the entire API.

You know, start by explaining in detail what it does. Explain this is 2 libraries in one. Domino is a reimplementation of incremental-dom in Dart. But it includes a library on top, domino-html, which provides a better API for writing HTML in Dart, with type safety. The user can use one or the other. Talk about the whys.

Just 2 hours spent writing documentation would bring so much value to this library, in my opinion.

[isoos]

Just 2 hours spent writing documentation would bring so much value to this library, in my opinion.

I agree. If this would be my only library out, or if it had more reports on the need here, I may be compelled to spend much more time there. But the truth is: we have many things in our lives, all the time, and some things are not at high priority. Hence, contributions are welcome, even if they are in the form of questions. There is very little point to document something that only I use, but otherwise how would I know if there is an interest in the documentation?

If I were reimplementing a library that has been maintained by Google for, I don't know, 8 years?, I would think real hard about any changes. In this case, you removed a feature, but I don't understand your reasoning.

Note: my goal here is not a full 1:1 reimplementation of a specific library. I like the original concept, I had use for it, but the library is not the slave of the implementation of the inspirational source.

The only thing is, static attributes are skipped on updates.

But you can't really skip them: unless you mark the DOM node otherwise, unless you keep track of the static attributes you have already applied and you are planning to reuse, you need to check them. At that point, there is not much of a difference checking one or two sets of attributes.

[isoos]

To demonstrate why there is a little difference between the two sets, let's consider this:

if (condition) {
 renderAWithStaticAttr1();
} else {
  renderBWithStaticAttr2();
}

Once you render A, and you repeat rendering A, the static conditions may seem to be something you don't need to check. But you don't know when the user code switches to B, and at which point the already set "so-called static" attributes need to be changed. Hence, you need to check them on each rendering anyway.

[nandoflorestan]

I see your point (only after reading the example, not before, such is the importance of a good example). So now the question in my mind is whether this is a bug in the Google code, or they managed to do something different... or they just didn't care about absolute correctness, trusting the optimization would work fine for most (but not all) use cases...

I also remember that incremental-dom has another optimization that requires the collaboration of user code. Inside loops, user code can provide an ID as an argument, which helps the renderer understand if an element has been removed, added or just modified. I wonder if you have something similar in domino?

By the way, as I read the examples and tests, I am having a hard time finding one with a for loop. I don't think we have one yet.

[isoos]

I also remember that incremental-dom has another optimization that requires the collaboration of user code. Inside loops, user code can provide an ID as an argument, which helps the renderer understand if an element has been removed, added or just modified.

I have only vague memories, but I think they did trust the user code being correct and used that as an optimization step.

I wonder if you have something similar in domino?

If you are using the low-level API, DomBuilder.skipNode and DomBuilder.skipRemainingNodes can be used to skip nodes (and their subtree) from matching/verification. This is useful for components that manager their internal state separately from domino.

There is also a key parameter on DomBuilder.open (also in DomElement constructor) which acts an element-identifier (or it may fall back to the id attribute, so key is a non-user visible reuse-key). When it is present, it will be used to select the immediate child element for reuse:
https://github.com/agilord/domino/blob/main/domino/lib/src/browser_impl.dart#L146

This is useful e.g. when you have a table and the rows get reordered by a different column: it can still reuse most of the content by identifying the appropriate "old" row...

By the way, as I read the examples and tests, I am having a hard time finding one with a for loop. I don't think we have one yet.

Yeah, I had an app that used it, but didn't put much effort to extract it as a test. :(

[nandoflorestan]

Key! Where I wrote ID, I meant the "key" argument. But I think in incremental-dom the key identifies the element being opened. You are saying in domino the key argument identifies a child element? How would that work?

Sorry, I am having a difficult time following the code you linked. I am still just trying to understand the public API.

[isoos]

You are saying in domino the key argument identifies a child element? How would that work?

You specify key on creating the element (whether it is open or DomElement), and it is being used in the subsequent re-rendering runs. However, it is not used arbitrary across the entire DOM, there is no global key lookup at any given point that pulls in another DOM subtree. It is only used in the current sibling context (hence the reference to children, as it is the children of the same parent).

Sorry, I am having a difficult time following the code you linked. I am still just trying to understand the public API.

Yeah, totally get it. One way to start is to go with the DomElement API, it is much easier to grasp:
https://github.com/agilord/domino/blob/main/domino/test/browser/counter_component_app.dart#L20

Also, if you use domino_html, it will have nice, typesafe API like the following, helping the creation of said DomElement instances: https://pub.dev/documentation/domino_html/latest/domino_html/div.html

[nandoflorestan]

Again, not grasping whether you are talking about children but actually meaning siblings. Again, doubt will only be dissipated by an example. Is this normal usage of key?

<ul><li key="42">User István whose ID is 42</li></ul>

(I wrote the example in HTML to save time.)

When you spoke of children, I thought you might mean this:

<ul key="app:identifier"><li app:identifier="42">User 42</li></ul>

But it's the first example, isn't it?

[isoos]

Yes, the first.