compose method and yields

[stefanoborini]

I am evaluating textual for a project I need to implement at work.

I have a very lightweight understanding of it, but something that just rubs the wrong way from the design point of view is the compose() method and the large need to write the layout of the view as a set of yield/with statements, rather than a widget tree.

Is there any actual advantage to this approach, and is there a way to define the view in a way that does not require yield/with logic for each little component of the view?

[davep]

a widget tree

How do you envisage this working/looking?

Note that container widgets generally take the list of children as a parameter, and compose can return a list. So if you really wanted to, you could write something like this:

with Parent():
    with Child():
        yield Grandchild()

as:

return [Parent(Child(Grandchild()))]

[stefanoborini]

Ok, so that already works as I envision? Exactly as you write. Return a (potentially dynamic) list of subwidgets.

Still, I am curious about the motivation to make the compose method a generator. Is there some event driven async-ness that comes from times before the async/await introduction, or is it just to have it return a generator instead of a list?

[willmcgugan]

The generator approach is more expressive, and easier to edit. The natural indentation of the with block expresses nesting without the need for so much parenthesis. It also allows you to express dynamic constructs more naturally.

Adding logic is quite natural with the generator approach, but more awkward with a list.

with Parent():
    if show_children:
        with Child():
            for child in range(kid_count):
                yield Grandchild(id=f"kid{child}")

But all that is required is for it to return an iterable of Widgets. So as @davep pointed out, you are free to return a list.