User story: I log in, i begin editing a story, and my crappy internet connection fails. or my rickity old computer dies. Or my browser crashes. Or i hit refresh. In all 4 scenarios, the "componentWillUnmount" lifecycle trigger never happens, meaning I'm still in that list of "currentEditors". That means, I can't trust the client to take me off the currentEditors list, it has to come from the server when it receives an unsubscribe. Then, i can take that socketId and remove it from the recently unsubscribed channel. But, ultimately we want names, not ugly socketIds. So, since 1 username has many connections, we'll have to create a separate "Connections" table that links a connection to a userId or userName.
User story to explain: Jan is on her laptop & tablet. she is editing the same field from both (Jan is a freak). The activeLabel just shows "Jan" once. She realizes she's a freak, logs off her tablet & even though she's still editing on her laptop, it says she's no longer a currentEditor.
mattkrick
commented
8 years ago
User story: I log in, i begin editing a story, and my crappy internet connection fails. or my rickity old computer dies. Or my browser crashes. Or i hit refresh. In all 4 scenarios, the "componentWillUnmount" lifecycle trigger never happens, meaning I'm still in that list of "currentEditors". That means, I can't trust the client to take me off the currentEditors list, it has to come from the server when it receives an
unsubscribe. Then, i can take thatsocketIdand remove it from the recently unsubscribed channel. But, ultimately we want names, not ugly socketIds. So, since 1 username has many connections, we'll have to create a separate "Connections" table that links a connection to a userId or userName.User story to explain: Jan is on her laptop & tablet. she is editing the same field from both (Jan is a freak). The activeLabel just shows "Jan" once. She realizes she's a freak, logs off her tablet & even though she's still editing on her laptop, it says she's no longer a currentEditor.