-
Notifications
You must be signed in to change notification settings - Fork 826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change emit to post to self. #1738
Conversation
It occurs to me that I'm wondering if there is a legitimate need for something which posts to a parent, or we just drop the concept altogether in favor of |
In my mind, I thought that |
I also think it makes sense to have a shortcut for a widget to post a message to itself, but perhaps it'd be better named |
But |
Yeah, you are right 🤦 |
Give it a go. I feel sad to get rid of |
Done in bd719e0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one tiny error. Have you searched the entire code to make sure there aren't any emit
s hiding in docs or examples?
docs/blog/posts/on-dog-food-the-original-metaverse-and-not-being-bored.md
Outdated
Show resolved
Hide resolved
Yes, I've searched the codebase and the documentation (and the examples therein). |
Makes sense to update all the docs to reflect the work done in Textualize#1738 but I feel it doesn't quite make sense to retrofit this into an old blog post -- especially if the code it is referring to was like that at the time and likely still will be for a wee while after this gets republished.
The point of this PR is that it makes it simpler to subclass widgets because you can capture messages that would be sent by the parent and repurpose them.
E.g., in the app below, the subclass of
Input
no longer emitsInput.Submitted
events, but ratherMyInput.MyMessage
events.Code