feat(api): add SERIALIZE_TO_IPC_FN const and implement it for dpi types, add more constructors#11191
feat(api): add SERIALIZE_TO_IPC_FN const and implement it for dpi types, add more constructors#11191
SERIALIZE_TO_IPC_FN const and implement it for dpi types, add more constructors#11191Conversation
Package Changes Through bc08c82There are 9 changes which include tauri with minor, @tauri-apps/api with minor, tauri-bundler with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-utils with minor, tauri-runtime-wry with minor, tauri-macros with patch, tauri-runtime with minor 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 |
toIpc method on dpi types, add more constructorstoIpc and toJSON method on dpi types, add more constructors
|
this one can wait to be merged after the v2 stable release right? |
Co-authored-by: Tony <68118705+Legend-Master@users.noreply.github.com>
Legend-Master
left a comment
There was a problem hiding this comment.
Do you think we should use toTauriIpc instead of just toIPC?
yes, i am not to keen on |
|
Made a |
|
Sounds good to me, but shouldn't the symbol be a |
Normally it should be, but we access this value in multiple places and we can't keep re-defining it because it will not be the same value (that's how Symbol works, it is always unique). We can define it on the global const ToIPCSymbol = window.ToIPCSymbolbecause it will break usage with next.js and SSR framworks and I don't want to deal with their issues again. |
|
Never mind, we can't use import here |
|
What about |
|
That works I guess but is it really that different? the main problem here IMO is that we can't share the value by using imports |
|
Right, that doesn't really make a difference, let's just go with a string then, in that case maybe changing the name to |
|
renamed! |
Legend-Master
left a comment
There was a problem hiding this comment.
Didn't test it, but the code looks good to me
| * | ||
| * @since 2.0.0 | ||
| */ | ||
| [SERIALIZE_TO_IPC_FN]() { |
There was a problem hiding this comment.
I like the whole toIPC approach (makes the __CHANNEL__ thingy available to anyone) but this is actually a breaking change - existing commands relying on PhysicalPosition / PhysicalSize / LogicalPosition / LogicalSize cannot deserialize this new format, so we should revert these - if you explictly want a generic Position or Size type we need to create a wrapper type just like Rust has one
There was a problem hiding this comment.
that makes sense, I have added Position and Size classes and reverted breaking changes.
toIpc and toJSON method on dpi types, add more constructorsSERIALIZE_TO_IPC_FN const and implement it for dpi types, add more constructors

No description provided.