-
Notifications
You must be signed in to change notification settings - Fork 78
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
Make Desktop's DTOs reflect status-go types again #11694
Comments
I generally agree with the sentiment. I guess part of why this is so inconsistent is also because it would mean even more boilerplate code to get values to and from the UI layer. For example, the ^ In this case we'd actually need to introduce yet another type that is able to adapt between service layer <-> view layer. I'm not saying I'm disagreeing, quite the opposite, but often times it's already a pain to introduce new data structures just to get some primitive value carried all the way to the user interface. I guess once all necessary domain types are in place, this will be less annoying. But it'll be a significant amount of work to get there. |
The evolution of
type ChatMember* = object
id*: string
admin*: bool
joined*: bool
+ roles*: seq[int] type ChatMember* = object
id*: string
- admin*: bool
joined*: bool
- roles*: seq[int]
+ role*: MemberRole type ChatMember* = object
id*: string
joined*: bool
role*: MemberRole
+ airdropAccount*: RevealedAccount
|
I think the root of the problem is the type inconsistency coming from status-go. status-go signals chat changes through protocol's Chat, while explicit fetch is done through API's Chat. Sadly, they are not the same. For instance, they differ in how members are represented: protocol:
api:
status-desktop assumes |
Does
I agree. In ideal world, domain types should be DTOs. We wouldn't need extra types if status-go is consistent and sends what we need.
Right. I believe we can go hybrid. Treat DTOs as domain types as long as they are mapped 1 to 1 with what status-go represents and introduce domain types only when needed, a good example of that: https://github.com/status-im/status-desktop/blob/master/src/app_service/service/contacts/dto/contact_details.nim (now I realized it shouldn't be inside the dto subfolder). |
Ah no, it's not exactly that. But there are |
Description
DTO types that are defined in
src/app_service/service/*/dto/*.nim
should mirror the types in status-go. This used to be the case, but it has diverged over time. This is causing confusion, making the code hard to follow and difficult to reason about, which in turn negatively affects code extensibility and maintainability. This issue is particularly evident when data from status-go needs extension or adaptation.As an example,
ChatDto
'smembers
field does not reflect status-go'smembers
field ofChat
.status-go:
status-desktop:
This discrepancy is resulting in the following logic:
As can be seen,
toChatDto
is being called on different JSONs. It's impossible to understand the intent from the code without inspecting these JSONs, the flows, and where they differ.Proposal:
src/app_service/service/*/domain/*.nim
Chat
type with fields relevant to status-desktop and useChatDto
only for parsing and services processing.The text was updated successfully, but these errors were encountered: