-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass mention list up and down #34
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep the naming style consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep the schema protection in your modification.
src/schemas/message.ts
Outdated
toId? : string, // if to is not set, then room must be set | ||
} | ||
|
||
/** @hidden */ | ||
export interface MessagePayloadTo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not simply merge those interfaces. They are separated by design.
We need to make sure that: either fromId
or roomId
must exist
The original design is to protect those data schema; please do not remove this protection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, if that's the case, we should have no roomId
in the MessagePayloadTo
, and no fromId
or toId
in the MessagePayloadRoom
, right?
Could you please explain a little about the reason that we have that at the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to current design, maybe you will agree with this design?
export interface MessagePayloadBase {
id : string,
// use message id to get rawPayload to get those informations when needed
// contactId? : string, // Contact ShareCard
filename? : string,
text? : string,
timestamp : number, // Unix Timestamp(in seconds)
type : MessageType,
}
/** @hidden */
export interface MessagePayloadRoom {
fromId? : string,
mentionIdList?: string[], // Mentioned Contacts' Ids
roomId : string,
toId? : string, // if to is not set, then room must be set
}
/** @hidden */
export interface MessagePayloadTo {
fromId : string,
mentionIdList?: string[], // Mentioned Contacts' Ids
roomId? : string,
toId : string, // if to is not set, then room must be set
}
export type MessagePayload = MessagePayloadBase
& (
MessagePayloadRoom
| MessagePayloadTo
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but I don't think this is right: the MessagePayloadTo should never have the mentionIdList property.
Then why it has |
So what was the reason that we have the |
To be honest, I forgot. The only thing that I had remembered is that it was designed for a purpose. Would love to discuss it with you when we got time, but let's just move forward and leave this as it is. |
Cool, let's talk then. And thanks for merging this PR :) |
Refer to issue: wechaty/wechaty#1560