Can I stash instances of things and expect it to work?

[DanCardin]

In 1st party textualize-written code, I see patterns like this used a lot:

class Foo(Widget):
    def compose(self):
        yield Select(id='foo')

    def somewhere_else(self):
        control = self.query_one('#foo')
        ...

Is there any reason the following wont work instead? (e.g. the widget instance references arent stable-ly going to be the same object as what's on screen)

class Foo(Widget):
    def __init__(self):
        self.select = Select(id='foo')

    def compose(self):
        yield self.select

    def somewhere_else(self):
        control = self.select
        ...

I've started doing this to avoid the query system and it seems to JustWork. In my current cases, I can usually statically know the set of screens/widgets/etc that a given thing is going to produce given the contructor args for the object in question. And by doing so, i can have stronger typing on the existence of these objects.

In fact, even with things that are more dynamics, like mutable lists of controls, it seems easier to append to a typed list of controls than to formulate a query and get back an unknown collection of widgets.

I'd perhaps even resort to this pattern for non-direct descendant objects by passing them into the constructor of my e.g. widget rather than querying for them, for all the same reasons. Although obviously this has a cost and i'm sure there are some scenarios where the query system would be more ergonomic.

tl;dr am i missing something fundamental about reactivity or whatnot where doing this is going to bite me versus using the query system?

[willmcgugan]

Sure, you can. But I would avoid it for a few reasons.

• If you add it to the constructor, you have to repeat the constructor arguments.
• If you recompose your widget, you will get a different instance, so your self.select may not work any more.
• You risk using a widget after it has been removed from the DOM, resulting in puzzling errors, where a query would have given you more information.

Note that if you do select = self.query_one("#foo", Select), then your type checker will understand it is a Select widget. Ditto with for select in self.query(Select): Your type checker will know they are instances of a Select.

[DanCardin]

So i guess ignoring my comment about passing in distant widgets as arguments, and assuming that in all cases it's direct child nodes that i'm asserting will always exist in the context of the current node existing.

i'm not sure under what circumstances i would be re-composing my widget; but I would assume that'd call .compose() again, and then my component would yield the original self.select again, so it would still be the same instance and it would still end up just working? I feel like the only way it doesnt work is if the widgets themselves are stateful in a way that would break upon being recomposed.

good to know re self.query_one("#foo", Select), that goes much of the way towards addressing my issues, but i still need to then guard against None all over the place where i know there's a one-to-one correlation (in most cases) between the widget i'm operating in the context of and some widget i'd be saving/querying for. For that reason i'm not sure bullet 3 would be relevant (because the containing widget would have already been removed from the DOM and i wouldn't be(?) executing self code in the context of the parent anymore anyways?

Something like a get_one that internally asserts not None would solve my problem, but then i'd still wonder how query is benefitting my code (self.select vs self.get('#foo', Select) all over the place), since it seems like it's necessarily evaluating a lot of stuff to get the reference that I could be directly using (again, assuming there aren't fundamental issues/bugs that will result from not querying)

[willmcgugan]

If you recompose, the current widgets will be removed, including any attribute you have stored. Adding a widget after it has been removed, will break unfortunately.

query_one should never return None, so no assert should be required.

query_one is generally fast enough for it to not be a concern, however you could use get_child_by_id for the fastest lookup.