-
-
Notifications
You must be signed in to change notification settings - Fork 87
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
Add getWebxdcHref to json api #6281
base: main
Are you sure you want to change the base?
Conversation
1fef259
to
73a0371
Compare
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.
did not test, but looks good :)
and if it compiles, it's perfect :)
I tested it with deltachta-desktop |
let message = Message::load_from_db(&ctx, MsgId::new(instance_msg_id)).await?; | ||
Ok(message.get_webxdc_href()) |
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.
performance-wise, it might be better to add href
as a property to the "js message object", similar to "info type" or "text".
maybe it does not matter much, as it is currently used only when actually tapped, but that may change.
no blocker, sure.
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.
Yes thats what I also thought would be better, but I wondered if there was a reason to have a explicit function defined
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.
I think I will extend it if you agree
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.
internally, it is in "param", therefore there is a getter-function, so that UI do not need to think about that detail.
but these getters are cheap, no db-call needed.
in C-FFI, this is quite strict, as a rule of thumb, i.e. you load a dc_msg_t which requires a single db call - all dc_msg_getters do not use db calls -- in js land, the object loading is similar, but often needs much more db calls)
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.
yeah, feel free to extend or to keep the current state. this mainly affects desktop and is also easily changable
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.
I think in this case explicit function might be better, because the webxdc-info object might be cached in ui/react-component, unless it was updated by message changed event?
Atleast such a dedicated function might be simpler to understand?
anyways depends heavily on how/where you use the information in desktop, like:
- pass the href in open call from ui to backend
- or just call open and open-handler in backend retrieves the href then to know where to open to.
@@ -1829,6 +1829,17 @@ impl CommandApi { | |||
WebxdcMessageInfo::get_for_message(&ctx, MsgId::new(instance_msg_id)).await | |||
} | |||
|
|||
/// Get href from a webxdc message |
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.
The naming and doc comment does not tell much, unless you have already read the webxdc docs, it is not easy to figure out what it means.
An additional sentence what href is in this context would help.
No description provided.