Add common component conditions

[Shatur]

Add two useful common run conditions for components similar to any_with_component from #7579. Unlike any_with_component these two conditions could be potentially expensive, but super useful if user knows that there is only a few entities with a component.

---

Changelog

Added

• Add any_component_added and any_component_changed.

[alice-i-cecile]

Otherwise this check could be expensive and hold up the executor preventing it from running any systems during the check.

I think this can be more clearly phrased by replacing your warning with the following:

Run conditions are evaluated on the main thread, blocking any other systems from running.
This run condition is relatively expensive, as it iterates over every entity with this component.
As a result, you likely only want to use this run condition when the number of entitities with the component T is small.

One more request: can we have the same flavor of run condition, but for RemovedComponent<T>?

[Shatur]

I think this can be more clearly phrased by replacing your warning with the following:

I like it!

One more request: can we have the same flavor of run condition, but for RemovedComponent?

I think we switched to events for this: #5680

[alice-i-cecile]

I think we switched to events for this: #5680

That PR was effectively non-breaking :) The RemovedComponents system param is still around, it's just now double-buffered and no longer quite as bespoke.

[Shatur]

The RemovedComponents system param is still around, it's just now double-buffered and no longer quite as bespoke.

Right, missed that it was an internal change. Will add the condition.

[Shatur]

Right, missed that it was an internal change. Will add the condition.

We probably should add RemovedComponents::is_empty() for it to avoid calling iter().count().

[james7132]

These potentially do a full world scan in the multithreaded executor, which not only runs single threaded but blocks any further system's run conditions from being evaluated and tasks launched. The only early return is if no archetypes match the query, everything else does a full scan, and will scale linearly with the number of those components in the world. This is relatively easy performance footgun, same with the other condition below.

Even with it documented, I still don't think it's a good idea to readily provide this to users without some form of archetype-level change detection optimization.

[Shatur]

Yep, this is what I mentioned in the description. I thought it's fine if documented. But your concern is exactly why it wasn't included in #7579.

[inodentry]

Suggesting better wording for the doc comments!

[Shatur]

Thanks!

[inodentry]

Other than the little things I pointed out above, I approve! Given the warning in the documentation, I think this is worth including in Bevy.

As implemented, if, in the future, change detection gets optimized so that the queries don't have to iterate, this API will just magically become fast, and we can remove the perf warning. :)

[Shatur]

I moved non-controversial any_component_removed to a separate PR (#8326) that was merged. Updated this PR with to the latest master just in case someone will be interested to include these two other conditions.

[Shatur]

It was decided to not implement it, closing.