Is it an internal implementation limitation that causes this discrepancy? It does seem like a deliberate design decision in certain case - root level "ID" keys on API models are almost always _id instead of id (while any nested objects or sub-objects use id instead). However this bothers me for two reasons: General inconsistency, but also how Bonfire events are documented.
Take the EmojiCreate event:
The "Emoji" model contains an _id key, so I assume the event would have the field serialized this way when sent over the websocket.
However, you see the EmojiDelete event right below it, and now the same identifying field is serialized as id instead.
It would be nice to unify their naming in one way or another. I am fine with _id everywhere, but consistency is the goal of this request.
What do you want to see?
Is it an internal implementation limitation that causes this discrepancy? It does seem like a deliberate design decision in certain case - root level "ID" keys on API models are almost always
The "Emoji" model contains an
_idinstead ofid(while any nested objects or sub-objects useidinstead). However this bothers me for two reasons: General inconsistency, but also how Bonfire events are documented. Take the EmojiCreate event:_idkey, so I assume the event would have the field serialized this way when sent over the websocket. However, you see the EmojiDelete event right below it, and now the same identifying field is serialized asidinstead.It would be nice to unify their naming in one way or another. I am fine with
_ideverywhere, but consistency is the goal of this request.