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
In short, Time.every has a very different behaviour than setInterval, subscriptions to an equal amount of time (i.e, the first argument of the function) get bundled together instead of getting treated as separate subscriptions, with different start times. This creates a very weird behaviour exemplified below.
In this example we have two 5 second subscriptions to Time.every. One is created on init, the second is created after 3 seconds have passed. The expected behaviour would be that at the 5 second mark, only the first message gets triggered, and at the 8 second mark, the second one is.
Why this is weird:
The above behaviour could be considered ok, but it means that we get strange interactions, in the above example, if we change the second 5-second subscription to use a 4.999s rate, we get the expected behaviour (one that works like setInterval).
Problems and possible solution:
I don't think that this problem can be fixed with the current API, it looks like we'd need to add a key or something to Time.every to identify different calls to the subscription with the same period.
If we do, fixing this should be simple enough, instead of just using the period as the key in the manager's state, we could use the pair (stringKey, period) or something.
The text was updated successfully, but these errors were encountered:
Description:
In short,
Time.every
has a very different behaviour thansetInterval
, subscriptions to an equal amount of time (i.e, the first argument of the function) get bundled together instead of getting treated as separate subscriptions, with different start times. This creates a very weird behaviour exemplified below.Example: https://ellie-app.com/8h5QfbhS6Dka1
In this example we have two
5
second subscriptions toTime.every
. One is created on init, the second is created after3
seconds have passed. The expected behaviour would be that at the5
second mark, only the first message gets triggered, and at the8
second mark, the second one is.Why this is weird:
The above behaviour could be considered ok, but it means that we get strange interactions, in the above example, if we change the second 5-second subscription to use a 4.999s rate, we get the expected behaviour (one that works like
setInterval
).Example of this second case here: https://ellie-app.com/8h5VgDkD7PMa1
Problems and possible solution:
I don't think that this problem can be fixed with the current API, it looks like we'd need to add a key or something to
Time.every
to identify different calls to the subscription with the same period.If we do, fixing this should be simple enough, instead of just using the period as the key in the manager's state, we could use the pair
(stringKey, period)
or something.The text was updated successfully, but these errors were encountered: