Presence onJoin callback includes old metas in newPresence var #3475
Comments
|
Also, onJoin and onLeave both call a function with 3 arguments: key, currentPresence, newPresence OR leftPresence. The currentPresence however seems to be different for both of them: onJoin currentPresence value is the same value as before the update. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. I'm ok submitting a PR but I'm not really sure what is the correct behavior here. |
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Aug 5, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to salemove/phoenix
that referenced
this issue
Aug 6, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Sep 6, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Sep 6, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Sep 6, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Sep 6, 2019
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to salemove/phoenix
that referenced
this issue
Feb 5, 2020
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this also helped to get rid of the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Feb 6, 2020
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Feb 6, 2020
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to indrekj/phoenix
that referenced
this issue
Feb 14, 2020
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
indrekj
added a commit
to salemove/phoenix
that referenced
this issue
Apr 15, 2020
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
bautrey37
pushed a commit
to salemove/phoenix
that referenced
this issue
Nov 16, 2021
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
bautrey37
pushed a commit
to salemove/phoenix
that referenced
this issue
Jan 4, 2022
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
laurglia
pushed a commit
to salemove/phoenix
that referenced
this issue
Aug 18, 2022
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
laurglia
pushed a commit
to salemove/phoenix
that referenced
this issue
Aug 18, 2022
Syncing presences was very slow due to using clone(). For channels that have couple of thousand of users where users are joining/leaving and we also have updates, clone() used almost all the CPU. onJoin and onLeave callbacks were merged into one onChange callback. This is because previous onJoin and onLeave callbacks were very confusing and this way we don't have to use the the clone function. Previously onJoin and onLeave both were called with 3 arguments: key, currentPresence and newPresence/leftPresence. The currentPresence however was the same value as before the update for onJoin, but updated presence (joins/leaves processed) for onLeave. So in onJoin case we get the state before the changes and in onLeave case we get the state after all the changes. Also the old onJoin newPresence variables included metas that were in leaves payload which made it hard to detect a join vs an update. New onChange callback includes the previous presence (state before the updates) and new presence (state after the updates) which makes it much easier to process changes and see what has happened. onJoin and onLeave are still in the API because of backwards compatibility but they're marked as deprecated. This addresses both phoenixframework#3509 and phoenixframework#3475
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Issue
Given: I have a user with one tab (one meta)
When: I update the user (from phoenix presence in elixir)
Then: I expect
newPresenceto include one meta with the updated dataACTUAL:
newPresencehas two metas, one old and one updatedIf I force onJoin to next event loop like this:
then
newPresenceincludes only one meta which is the updated meta, which I actually expect.Digging in the code
As I understand then here https://github.com/phoenixframework/phoenix/blob/master/assets/js/phoenix.js#L1329
state[key]is set tonewPresence. Thenstate[key].metas.unshift(...curMetas)adds current metas to the state[key]. This however also mutates thenewPresencebecause the var was not cloned. ThenonJoin(key, currentPresence, newPresence)is called wherenewPresencenow has the old metas as well.setTimeout works because this forces https://github.com/phoenixframework/phoenix/blob/master/assets/js/phoenix.js#L1337 to iterate over leaves which mutates newPresence to be correct again.
It seems to be that this is not a correct behavior. If it is, can you explain why?
The issue does not exist with
onSynccallback because that's called after both joins and leaves are processed. We however don't want to useonSyncbecause we want unchanged presences to remain referentially equivalent whichonSyncdoes not provide as it clones the entire list. Our online user list has thousands of users and we want to leverage referential equivalence and also don't want to map over the whole list each time for fast react based dom updates.The text was updated successfully, but these errors were encountered: