This Runtime Meta-Programming Pattern in Python is Interesting

Background

I’m currently working on a UI framework built on top of Pyodide, called Zenaura. Recently, I noticed that the builder interface — the main way users create UI elements — was a bit too complex and unappealing. While it does abstract the underlying, more cumbersome interface for interacting with Zenaura's virtual DOM "Node" data structure, it still wasn't satisfactory. I wanted to simplify things and provide users with a cleaner, more intuitive experience, all while laying the groundwork for potentially developing a compiler for a completely new syntax. Something like this:

div(child1, child2, child3,attr1=val1)

Problem Statement

The current builder interface is too low-level and user-unfriendly. Users shouldn’t have to interact with something like this:

builder = Builder(name__)
if children:
    builder.with_children(*children)
if attributes:
    builder.with_attributes(**attributes)
if text:
    builder.with_text(text)
# print("data", builder.node.children, builder.node.attributes)
return builder.build()

Instead, they should be able to use a cleaner, more readable syntax like:

div(
h1("text"), 
p("text"),
id="some-id"
)

Looking at the MDN docs, there are 91 HTML tags, with the possibility of additions or deprecations. I initially considered dynamically generating the code to simplify this process, but while it works, it's not the most practical solution. The primary goal was to show docstrings whenever a user calls a function, but the dynamically generated approach introduces some challenges, such as a lack of auto-completion.

The Dynamic Approach

Here’s the dynamically generated code that I experimented with:

tag_config = {
    # root elements
    "html": "nestable",
    "main": "nestable",
    "body": "nestable",
}

tags_factory = {
    "nestable": lambda name__: f"""
{name__} = partial(nestable, "{name__}")
""",
    "textable": lambda name__: f"""
{name__} = partial(textable, "{name__}")
""",
    "self_closing": lambda name__: f"""
{name__} = partial(self_closing, "{name__}")
""",
    "nestable_no_attrs": lambda name__: f"""
{name__} = partial(nestable_no_attrs, "{name__}")
"""
}

for k, v in tag_config.items():
    exec(tags_factory[v](k), globals())

This works well in terms of functionality but falls short on usability. The main drawback is the lack of autocomplete, since the code is injected at runtime. However, HTML tags themselves are relatively simple, so this isn't as much of a concern for now.

Benefits and Limitations

One of the significant advantages of this approach is flexibility. Supporting or deprecating a html element in Zenaura is as easy as adding or removing a key-value pair from the tag_config dictionary. It’s a straightforward way to adapt to changes in HTML tags over time.

Additionally, the only limitations is with auto-complete and showing doc strings to users, I think this is a tradeoff okay to make since html elements are pretty basic.

However, the trade-off comes in the form of usability: without auto-completion, users may face challenges when interacting with the interface. That said, I believe this is a good starting point for experimenting with new ways to handle tag elements in Zenaura.