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
Currently retrieving messages come back like this:
var messages = [
{
sender_id: 2,
recipient_id: 5,
content: “I am a message”,
created_at: timestamp,
updated_at: timestamp
},
];
It is an array of individual messages where my team is either the Sender or the
Recipient. Then in the JS I group them.We calculate the other team by it being
“Not me” and grep through all the teams to find the matching ID for the other.
We group them into conversations under the assumption that “Each converstion
is with the team who is not me”.
There are some additional manipulations done around sorting the messages by time,
and creating some properties based on the content of the messages themselves. So
the structure ends up like this after Javascript manipulation.
var conversations = [
{
conversation_partner: {}, // This is an object that is the team we are communicating with. Mostly to get their Name / Flag.
latest_message: {}, // This is an object that is identical to the latest message sent/receieved as part of this conversation.
messages: [] // This is identical to the array described above. We construct the rest of is conversation object around information contained within.
}
];
This structure breaks down when we stop being able to safely make these
assumptions. Eg: When it comes to Espionage, we are no longer a represented
team.
The way that I would like to solve this is to push the logic that the javascript
is currently handling over to the backend. There are a few different ways to do this.
The eventually structure that I would like to end up with is this:
var conversations = [
{
// Not sure we need any other properties here but we could do with an ID at the least.
messages: [
{
sender_id: 2,
sender_name: "Germany",
recipient_id: 5,
recipient_name: "UK",
content: "Stuff",
updated_at: timestamp
}
]
}
]
This is in many ways simpler, and there's good reason for that. Each Conversation
thread would still be between two nations, but we stop caring about who is who
on a larger scale. The reason is because we have the names of the Teams in the
messages themselves. So instead of saying "If this team_id is equal to myId,
display my Country Name," which is goddamn gross, I can just say "Display this
Country's name."
Like, literally I have this code in the app right now:
How gross is that? And it really should be nothing more than
{{message.sender_name}}
Then it should work for both Messages and Espionage because it no longer matters
who the player is. What it cares about is simply "Who is sending and who is receiving"
So, there are two changes from what we have with messages now, which are:
a) Include the name of the team in addition to the ID for both sending & receiving
b) Group the communications into conversations. Eg, if I am looking up the
messages for Brazil, I want to see every message that Brazil has sent or
received, and each nation they have communicated with is a separate object.
There are a couple of ways that I can think to handle this.
A super gross giant query.
The messages table contains a join table that relates to itself.
There is a separate Conversations table that Messages relate to.
Let's discuss these options and come to a consensus on what we think the best
approach is so that we can try and make this feature into a happy thing instead
of a giant well of sadness like it is currently.
The text was updated successfully, but these errors were encountered:
Currently retrieving messages come back like this:
It is an array of individual messages where my team is either the Sender or the
Recipient. Then in the JS I group them.We calculate the other team by it being
“Not me” and grep through all the teams to find the matching ID for the other.
We group them into conversations under the assumption that “Each converstion
is with the team who is not me”.
There are some additional manipulations done around sorting the messages by time,
and creating some properties based on the content of the messages themselves. So
the structure ends up like this after Javascript manipulation.
This structure breaks down when we stop being able to safely make these
assumptions. Eg: When it comes to Espionage, we are no longer a represented
team.
The way that I would like to solve this is to push the logic that the javascript
is currently handling over to the backend. There are a few different ways to do this.
The eventually structure that I would like to end up with is this:
This is in many ways simpler, and there's good reason for that. Each Conversation
thread would still be between two nations, but we stop caring about who is who
on a larger scale. The reason is because we have the names of the Teams in the
messages themselves. So instead of saying "If this team_id is equal to myId,
display my Country Name," which is goddamn gross, I can just say "Display this
Country's name."
Like, literally I have this code in the app right now:
How gross is that? And it really should be nothing more than
Then it should work for both Messages and Espionage because it no longer matters
who the player is. What it cares about is simply "Who is sending and who is receiving"
So, there are two changes from what we have with messages now, which are:
a) Include the name of the team in addition to the ID for both sending & receiving
b) Group the communications into conversations. Eg, if I am looking up the
messages for Brazil, I want to see every message that Brazil has sent or
received, and each nation they have communicated with is a separate object.
There are a couple of ways that I can think to handle this.
Let's discuss these options and come to a consensus on what we think the best
approach is so that we can try and make this feature into a happy thing instead
of a giant well of sadness like it is currently.
The text was updated successfully, but these errors were encountered: