Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

nicodh
Copy link
Contributor

@nicodh nicodh commented Nov 30, 2024

No description provided.

@nicodh nicodh requested a review from r10s November 30, 2024 15:44
Copy link
Member

@r10s r10s left a 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 :)

@nicodh
Copy link
Contributor Author

nicodh commented Nov 30, 2024

I tested it with deltachta-desktop

Comment on lines +1839 to +1840
let message = Message::load_from_db(&ctx, MsgId::new(instance_msg_id)).await?;
Ok(message.get_webxdc_href())
Copy link
Member

@r10s r10s Nov 30, 2024

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.

Copy link
Contributor Author

@nicodh nicodh Nov 30, 2024

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

Copy link
Contributor Author

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

Copy link
Member

@r10s r10s Nov 30, 2024

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)

Copy link
Member

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

Copy link
Member

@Simon-Laux Simon-Laux Nov 30, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants