Owned callbacks.

[viridia]

Defines a mechanism for registering callbacks which automatically unregisters the system when the parent entity is despawned.

[ickshonpe]

Could this support an API where the component boxes the system (or something like that) and then automatically registers it with an on_insert hook?

[viridia]

Could this support an API where the component boxes the system (or something like that) and then automatically registers it with an on_insert hook?

There's been some discussion on this: basically adding a different variant of Callback which would allow you to specify the system closure as an inline literal, avoiding the preregistration requirement. This is discussed in more detail in #19847 - unfortunately this is a tricky problem to solve.

I think we need both types of callbacks: ones that can be passed around from template to template as parameters, and ones that can be defined at the point of use.

[chescock]

Registered systems are entities themselves, so you might be able to skip having an extra entity by doing something like:

Suggested change

	self.commands()
	.spawn((OwnedCallbackSystem(system_id), crate::owner::OwnedBy(owner)));
	self.commands()
	.entity(system_id.entity())
	.insert(crate::owner::OwnedBy(owner));

I haven't thought through all the consequences of that, but thought it might be worth mentioning!

[alice-i-cecile]

I much prefer that design.

[alice-i-cecile]

I'm not convinced this is the right direction. If we're going to use one-shot systems, we should be leaning on the cached, persistent nature of them for deduplication across multiple buttons that do the same or related things.

If we're worried about cleanup, the simpler solution is to just store a closure on the widgets.

[viridia]

If we're worried about cleanup, the simpler solution is to just store a closure on the widgets.

A simple closure isn't going to get you dependency injection, and this is critical.

One of the pain points I discovered working with Quill is dealing with closure captures: having to constantly clone stuff and make dummy variables to satisfy the borrow checker. Once we introduced one-shot systems, I hit on a different strategy: replacing captured values with dependency-injected values. One substitutes for the other.

For example, say we have a widget with a callback, such that the callback wants to know certain things about the widget - like whether it's checked, focused, disabled, and so on. We can do this in a couple of ways:

• Make the callback exclusive and pass it an EntityWorldMut. However, working with exclusive access isn't the best DX.
• Convert all of these input sources into signals, which can be captured by the closure. Unfortunately, polling the signals still requires exclusive access.
• Use dependency injection. We still capture a few things, like entity ids, but since these are copy/clone capturing is easy. Then inside the closure, we re-derive from the injected params all of the things that we would have captured.

Using cached systems could work, if we could come up with a solution to the type-erasure problem. That's what #19847 is about - introducing some kind of dyn trait whose impl is able to internally know the concrete type of the callback and which can be shared between multiple call sites.