feat(api): add `SERIALIZE_TO_IPC_FN` const and implement it for dpi types, add more constructors
Package Changes Through bc08c820fc492b54780a37c17d6973467744f93f
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
this one can wait to be merged after the v2 stable release right?
Do you think we should use
toTauriIpcinstead of justtoIPC?
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.
Made a ToIpcSymbol const and used that instead.
Sounds good to me, but shouldn't the symbol be a Symbol not a string?
Sounds good to me, but shouldn't the symbol be a
Symbolnot 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.
Shouldn't this work?
Never mind, we can't use import here
What about Symbol.for()?
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 TO_IPC_KEY instead since it's not really a symbol?
renamed!