Most other Onyx methods return a Promise so this feels like an implementation oversight. However, there's also a practical advantage in that you might want to apply some updates in an atomic way and it's not possible due to the way mergeCollection() is implemented.
e.g.
Onyx.update([
{onyxMethod: 'merge', value: {isLoading: false}, key: 'someKey'},
{onyxMethod: 'mergecollection', value: {test_1: {a: 'a'}}, key: 'test_'},
]);Although called at the same time, this code will notify the subscriber of someKey first and we might assume the data from mergecollection is available as well - but there are no guarantees about this (and it is most likely not available).
If Onyx.update() returns a promise we can guarantee the correct order of events by doing something like:
Onyx.update(dataUpdate).then(() => Onyx.update(successUpdate));
This is much more predictable and will help solve the bug described here: Expensify/App#11726 (comment)
An future improvement could also be to make these updates atomic somehow - but I'm less sure what the solution for this would look like given the current state of Onyx's API.
Most other Onyx methods return a Promise so this feels like an implementation oversight. However, there's also a practical advantage in that you might want to apply some updates in an atomic way and it's not possible due to the way
mergeCollection()is implemented.e.g.
Although called at the same time, this code will notify the subscriber of
someKeyfirst and we might assume the data frommergecollectionis available as well - but there are no guarantees about this (and it is most likely not available).If
Onyx.update()returns a promise we can guarantee the correct order of events by doing something like:This is much more predictable and will help solve the bug described here: Expensify/App#11726 (comment)
An future improvement could also be to make these updates atomic somehow - but I'm less sure what the solution for this would look like given the current state of Onyx's API.