You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now change detection is set per updateEach call manually, default off. The proposal is to make change detection be on, off, or auto instead of a boolean, with default being auto. If auto then it would follow these rules:
All traits that are observed for changes with onChange are added to a tracking list.
If a query result selects for a tracked trait then it automatically enables change detection for that trait only.
If the trait is no longer observed, this is automatically switched off.
This can be overwritten by setting auto to off.
There was suggestion to make this even more specific, per entity per trait. There is no API for that currently (you can observe all entities for a given trait, not specific entities, and then filter for specific entities) so this should be opened as another issue.
The text was updated successfully, but these errors were encountered:
Looks good. Yeah I think entity + trait can be an implementation detail eventually. Since the public listening API requires you to pass an Entity in all cases anyway (unless I'm missing some?). Storing the tuple (trait, entity) in the tracking list should greatly reduce the number of comparisons and thus improve perf, making auto a save option in basically all cases. But since this issue is about the updateEach API, I think it's good as it is 👍
Right now change detection is set per
updateEach
call manually, default off. The proposal is to make change detection beon
,off
, orauto
instead of a boolean, with default beingauto
. Ifauto
then it would follow these rules:onChange
are added to a tracking list.auto
tooff
.There was suggestion to make this even more specific, per entity per trait. There is no API for that currently (you can observe all entities for a given trait, not specific entities, and then filter for specific entities) so this should be opened as another issue.
The text was updated successfully, but these errors were encountered: