Skip to content

Conversation

@edward-jazzhands
Copy link
Contributor

So - as I've mentioned in the Discord server before, if one is making a widget library, there are sometimes occasions when the widget needs to know when the DOM is completely ready. When making a widget library, you can't simply listen for the Ready event sent to the App class. I've had a couple conversations with some other people that make widget libraries which has lead me to believe that a simple, universal solution to this issue would be very useful.

There are various hacks to get around this of course. Previously to achieve this goal, I've been using a worker that just watches for App._dom_ready on a loop, that seemed to be the most foolproof and simple method. However, I recently taught myself about the Signal API and I realized it would actually be the perfect solution to this problem. Widget libraries can simply subscribe to this signal, and thus be alerted when the DOM is ready regardless of where it is in the DOM hierarchy.

I'm really hoping that this addition is a cake and not a puppy - that is to say, the addition of this signal should not have any affect on anything else or add any maintenance headaches.

I have tested this out in my own libraries and it works exactly as I intended, as well as of course passing all tests and whatnot. I feel quite confident about this PR since I think its solving a real problem in a simple and direct manner. Please let me know if you think there's any issues with this idea or if you'd like it to be modified - The Docstring maybe does not have the greatest wording!

@willmcgugan
Copy link
Member

What is it that your widget library does in response to the dom ready signal? What are you missing when your widget gets the Mount event?

@edward-jazzhands
Copy link
Contributor Author

edward-jazzhands commented Jun 1, 2025

In my case, I have a manager widget (invisible/hidden) that needs to be able to know that the app has been fully finished resizing its screen and all the widgets composed on to the app class, so that it can set window sizes and positions. It needs to know the size of all containers that all windows in the app are inside of in order to do this.

I think the crux of the issue is that I can't use the on_resize event for anything. That event is only sent if a widget starts displayed. In my case, because windows can start closed/minimized (with display=False), that method is never called and thus can't be used for initial setup. That's the reason why I needed to offload this logic out of the window class and into an external manager. Normally widgets could just on_resize that to know when its ok to start doing layout/size detection and whatnot, but I believe its not possible in this particular edge case.

If you think there is another way to easily achieve this same thing using some other technique, I'd definitely love to know about it. But nothing was effective in testing for me. Might just be because I didn't do it properly. I think a proper comparison of different techniques would be really useful here.

@willmcgugan
Copy link
Member

I think you can do this with call_after_refresh in your widget's on_mount.

One possible issue with the signal is that if you subscribe after the dom is ready, it will never invoke the callbacks. That might trip devs up.

@edward-jazzhands
Copy link
Contributor Author

Aha, indeed you are totally correct about call_after_refresh in the on_mount method. The DOM is ready when that callback is triggered. That's gotta be the one simple solution I didn't think to try!

Alright thanks a lot for your help, I'll declare this unnecessary

@edward-jazzhands edward-jazzhands deleted the add_dom_ready_signal branch June 23, 2025 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants