Skip to content

What Is This?

mastergray edited this page Jun 23, 2021 · 3 revisions

It's pretty much a virtual DOM, in that the YngwieElement class can represent DOM elements, can create and manipulate those elements without them being part of the DOM, and can render those elements into actual DOM nodes. It can also do the reverse though, using YngwieTransform to generate yngwieElements from existing DOM nodes, or generate yngwieElements from a STRING of HTML markup, e.g. <div>HTML Content</div>

yngwie node relationships are implemented as a linked list, which is why there is no "children" property. Instead, every YngwieNode instance, and it's subclasses, have references to their parent, first child, last child, next sibling, and previous sibling. There is a "children" method though that returns an array of nodes by iterating the first child's siblings until there aren't any siblings left to iterate.

It should also be noted that yngwie is not "reactive", which is why there aren't any "patch" or "diff" methods defined anywhere - yngwie's purpose is only to represent nodes that can eventually exist as nodes in the DOM, and to manipulate and alter those nodes before they are rendered and attached to an actual browser-based DOM client-side. As it stands now, rendering changes to the DOM can be accomplished manually by either appending or replacing nodes generated by YngwieElement's render instance method or by using the static YngwieElement methods renderTo and inject.

The YngwieListener class handles binding event listeners to elements at time of render. A yngwieListener rendered by a yngwieElement (e.g. event listeners bound to a yngwieElement using on) are called from the context of the yngwieElement they are bound to (i.e., that bound yngwieElement can be referenced by this from within the handler function) this opens up the possibility of re-rendering parts of the UI , without re-rendering the entire UI, when certain events are dispatched by the user or another listener. This approach however is admittedly clunky - and a more explicit MVC approach should be considered as a separate solution built on top of yngwie as opposed to something yngwie itself stives to support.