feat(api): add SERIALIZE_TO_IPC_FN const and implement it for dpi types, add more constructors

[amrbashir]

No description provided.

[github-actions]

Package Changes Through bc08c82

There 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 Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@tauri-apps/api	2.0.3	2.1.0
tauri-utils	2.0.2	2.1.0
tauri-bundler	2.0.4	2.1.0
tauri-runtime	2.1.1	2.2.0
tauri-runtime-wry	2.1.2	2.2.0
tauri-codegen	2.0.2	2.0.3
tauri-macros	2.0.2	2.0.3
tauri-plugin	2.0.2	2.0.3
tauri-build	2.0.2	2.0.3
tauri	2.0.6	2.1.0
@tauri-apps/cli	2.0.4	2.1.0
tauri-cli	2.0.4	2.1.0

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[lucasfernog]

this one can wait to be merged after the v2 stable release right?

[Legend-Master]

Do you think we should use toTauriIpc instead of just toIPC?

[amrbashir]

Do you think we should use toTauriIpc instead of just toIPC?

yes, i am not to keen on toIPC and don't want to make it collide with user types, so I was thinking maybe IpcValue class to extend like Resource class.

[amrbashir]

Made a ToIpcSymbol const and used that instead.

[Legend-Master]

Sounds good to me, but shouldn't the symbol be a Symbol not a string?

[amrbashir]

Sounds good to me, but shouldn't the symbol be a Symbol not a string?

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 window object and access from different places but so I don't want to expose this symbol in core module like this

const ToIPCSymbol = window.ToIPCSymbol

because it will break usage with next.js and SSR framworks and I don't want to deal with their issues again.

[Legend-Master]

Shouldn't this work?

[Legend-Master]

Never mind, we can't use import here

[Legend-Master]

What about Symbol.for()?

[amrbashir]

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

[Legend-Master]

Right, that doesn't really make a difference, let's just go with a string then, in that case maybe changing the name to TO_IPC_KEY instead since it's not really a symbol?

[amrbashir]

renamed!

[Legend-Master]

Didn't test it, but the code looks good to me

[lucasfernog]

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

[amrbashir]

that makes sense, I have added Position and Size classes and reverted breaking changes.