Description:
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.
Example: https://ellie-app.com/8h5QfbhS6Dka1
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).
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.
Description:
In short,
Time.everyhas 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
5second subscriptions toTime.every. One is created on init, the second is created after3seconds have passed. The expected behaviour would be that at the5second mark, only the first message gets triggered, and at the8second 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.everyto 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.