This is the same idea I had with my framework #624
rhengles
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I always found it very weird that React chose an architecture that creates an entire virtual dom and then compares all of it against the real dom. I always thought, "why don't they keep track of elements that use dynamic content and make sure that renders only ever update what's absolutely necessary?"
So I tried to start my own framework with this idea. Unfortunately I didn't have enough time to work on it. Now I found Solid, which is based on the same idea. Of course there are many details that are different.
Here is the link to my framework: https://github.com/arijs/ari
I would say the main difference between Solid and Ari is that the standard way of using Solid is with JSX, where Ari only support plain old "html" strings (not template strings). I don't know yet how Solid works when using template strings but I would like to learn more about it.
But Ari uses my own html/xml parser. I wanted it to be a ultra low level framework, like the user would be able to create his own "if" or "for" syntaxes - it could be attribute directives like Vue, or tag nodes, etc. It is based on a html string where dynamic content is associated with getter and setter funcions, like Solid.
The central idea of Ari is based on this:
Each component could be passed an
elementHandler
which is composed of sub handlers, each one will scan the template for its logic, doing its own work, and stop or continue processing with the next handlers on the queue, or use other handlers, etc.In the example above, each handler does the following:
ifAttr('a-if')
Creates an
if
directive (named 'a-if') that searches for this:htmlHandler
The default handler to render html tags (Yes, even this can be customised!).
When it finds a
<div>
node in the string, it renders a<div>
node in the dom. It renders all native html tags.Placing it here on the list is an optimization strategy. If the tag name is a native html tag, it is rendered and the handler queue is stopped. Otherwise, the next handlers will try to render the remaining tags.
fooCache
Here we begin to process custom Ari components.
Foo
here is a namespace of my custom components.The
Cache
part means that this handler contains a cache of already fully loaded component definitions, if this handler finds a component defined in theFoo
namespace, the component is rendered and the processing stops.This being here is an optimization. We could omit this handler from the list and everything would still work. But by being here, this handler checks if there is a tag on the html string that is a component already loaded from
Foo
. If yes, then the component is rendered and the handler manager can stop processing the rest of the handler queue.fooLoading
This handler is a temporary helper and optimization. If the html string requests a component that already has began to load asynchronously, but has not yet loaded, then this handler will prevent another loading to start, and will reuse the "loading" fallback component already defined on it.
myLoader
An example of a custom loader. By itself, it already contains all the logic to memoize component load requests, meaning that the same component will not be loaded twice, it can render loading and error states, etc. However, the "cache" and "loading" handlers for it are not manually defined on the handler queue list. This means that all steps will only be processed when/if the handler manager reaches this handler.
fooLoader
The loader for components in the
Foo
namespace. If the html string requests a component fromFoo
that is not yet loaded nor loading, then it starts loading the component, renders theloading
state, and add a reference to thefooLoading
handler. When the loading finishes, add a reference to thefooCache
handler.Beta Was this translation helpful? Give feedback.
All reactions