-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
feat(core): optimize raw payload in event system, closes #13405 #14269
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
base: dev
Are you sure you want to change the base?
Conversation
Package Changes Through 1259ca5There are 9 changes which include @tauri-apps/api with minor, tauri-cli with minor, tauri-utils with minor, tauri-runtime-wry with minor, tauri-runtime with minor, tauri with minor, tauri-bundler with minor, @tauri-apps/cli with minor, tauri-macros with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
we might need to introduce new JS functions too.. this actually breaks the data received on the backend side if you are sending array buffers using the current event system (which serializes it) |
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 kinda feel like it's a time to unify some channel and event staffs together 😂
* | ||
* @since 2.10.0 | ||
*/ | ||
async function emitTo2<T>( |
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.
Is this new function necessary? We're sending the same command to our rust side anyways no (as long as we handle both cases in rust side which I assume it's already the case when are calling it like this, it should be backward compatible)?
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.
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'm not sure I get it, isn't the new emit2
code the same as emit
in the previous revisions in the PR?
EmitPayload::Str(payload) => EmitArgs::new_str(event, payload)?, | ||
}; | ||
EmitPayload::Str(payload) => EmitArgs::new_str(event, payload), | ||
EmitPayload::Binary(payload) => { |
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.
This should be done with the same check (size check instead of binary type check) we did for the channel implementation or it will actually slow down smaller payloads
leverages the IPC to send raw data through the event system (similar approach to how channels send raw data through - associate data with an ID, and eval a script that fetches the actual data using the IPC to avoid serialization).
The JS API automatically uses the optimized interface, but Rust emitters should use
Emitter::emit_raw
andEmitter::emit_raw_to
to emit raw payloads, and readEvent::payload_raw
instead ofEvent::payload
.Ideally we would change types a bit to support both JSON and raw payloads, but we're introducing new methods to avoid breaking changes.