Add a "run if any system param changed" run condition (building towards reactivity)

[alice-i-cecile]

What problem does this solve or what need does it fill?

Various state synchronization systems only need to be run when their inputs have changed.

If we can skip scheduling them, we can save work! However, keeping up with that requires a ton of boilerplate.

What solution would you like?

WARNING: severe hand-waving ahead!

Create a simple ReactiveSystem trait, which caches information about the state of a system last time it ran (things like change ticks and event cursors).

For each system param, define a mechanism for it to check if things have changed. Events would use the event cursor, resource would use change ticks, queries might use the set of matched entities and/or change ticks.

A input_changed run condition would automatically inspect the system parameters, and then create a run condition system that caches and checks all of this information.

What alternative(s) have you considered?

Obviously, these run conditions could be composed manually for each system, by combining our existing run conditions like .resource_changed and .on_event. This isn't particularly ergonomic or maintainable though!

This idea can also be extended via constructing a diff of events / entities between the last and current time the system ran. In flecs, these are called monitors. This allows for a more granular diffing.

Additional context

This idea was inspired by the flecs approach to reactivity via observers, which are effectively "systems that run when their query changes".

While this run condition would be handy in its own right, I think its true value lies in the infrastructure it would require. These concepts of "has this system param changed" could be

[viridia]

It's hard to talk about this without invoking a lot of hazy metaphors. We have, on the one hand, a set of high-level ideas about what we want the ideal developer experience to look like. On the other hand, we have the code that exists today, and what it can do. Unfortunately, there's a large gap between these. What you've outlined above is a small step towards bridging that gap; but I can't predict whether it will actually lead to something that closes the gap or just creates yet another detour. We won't actually know until we have a plan for bridging the gap entirely.

I know this is rather abstract, so here's a more concrete scenario: the various sources of changes you have identified are low-level, and directly tied to actual entities in the world. However, working with MobX and Solid, I'd say about 10-20% of the signals you end up working with are derived computations, not primary data sources.

Take for example the focus ring: we want a widget to display a focus indicator when "me" (the entity) == input_focus.0. If we simply used the change bit from the InputFocus resource, then every time we change focus, every widget in the world is going to get notified and try to update it's visual effects. Instead, what the widget really wants to know is not "what widget has focus" (which results in an Entity) but rather "do I have focus" (which is a boolean). We really only want to be signaled when that boolean changes. So this is a boolean-typed signal that is derived from an Entity-typed signal.

Another use case is the dynamic sorted list. Say we have a table that lets you click on the column headers to change the sort order of the table. Say also that the list of sortable rows can change over time. That's two primary inputs: the (unsorted) list of rows, and the sort order. But what we want to actually display in the table is derived from both of those inputs: the sorted rows.

These two examples are relatively simple, but there are many more complex examples.

So how does this relate to your idea? Well, first I do like the idea of using dependency injection as a basis. One of the things I didn't like about my earlier experiments was the need to have world access everywhere, since in general you couldn't predict what kinds of data a given reaction would want to access and so the whole world needed to be readable. Also, I didn't like the idea that we had to invent this entirely separate API surface for accessing data elements reactively, completely apart from the way everything else in Bevy works.

The problem is that not every reactive data access pattern that we've seen fits into the dependency injection model. The derived signals examples I mentioned above are an example of this. Another area is contextual access: a lot of times the set of data we want to access from the world is determined by some captured closure variable. There's no way to encode this in a function signature. We've talked about adding Targeted to observers, but this is a more general problem. We don't want to react when every Foo changes, but only the Foos that are connected to our target entity in some way.

Co-location is another desirable feature. By co-location I mean that both behavior and hierarchical structure for a given entity can be defined together and not spread out into different modules and functions. Currently if you want to register a system that runs every frame (not a one-shot) that has to be done globally, at the app level. Thorium and bevy_reactor v2 didn't have this limitation, instead you could define systems inline within a template. (The way this worked is that it would register the system as a one-shot, and then store the SystemId in a component; a driver system would then go through, find all the components, and invoke the systems within.)

[cart]

I agree that reactive UI implementations almost certainly need to account for "passed around" derived values, that dependency injection likely can't be the full picture there, and might not even be a part of the final picture at all for UI. However I'm still personally of the mind that its worth exploring that avenue further / seeing how far we can take it.

"Reactive systems" (alternatively branded as something like "system-level change detection", leaving the "reaction" word unclaimed) are notably just an extension of the existing poll based Tick model. Even if they aren't a part of the final "official bevy UI" picture, I can still see them as a natural extension of the existing framework. And they would allow people to build "dependency injection driven reactivity" solutions in scenarios where that makes sense.

On the topic of "shared state" (such as shared systems or observers), I'm currently playing with an inversion of Construct (currently calling it Template, with a separate optional GetTemplate trait performing the role of mapping a type to its template) that would make it possible for scenes to define shared state like this (ex: by initializing a system and storing the id in the scene template).