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

[feat] OS info as constants and not async functions #1351

Open
wscourge opened this issue May 19, 2024 · 2 comments · May be fixed by #1353
Open

[feat] OS info as constants and not async functions #1351

wscourge opened this issue May 19, 2024 · 2 comments · May be fixed by #1353
Labels
enhancement New feature or request plugin: os

Comments

@wscourge
Copy link

wscourge commented May 19, 2024

Describe the problem

Given a scarce support for the top-level await, I'd like to have, at the very least, the osType exposed as a constant in the JS API (and not an async function, as it is now).

Describe the solution you'd like

Add this

import { OS_TYPE } from '@tauri-apps/api/os';

and don't make me call this anymore:

import { type } from '@tauri-apps/api/os';
const osType = await type();

Alternatives considered

For other people struggling with it at the moment: use the following ugly, bad, breaking, etc hack on the client side: window.navigator.userAgent.includes("Macintosh;").

Additional context

Electron does it.

It can easily come as a non-breaking change (supplementary to the current async type, arch and such). No need to deprecate the other stuff for a long time, too.

@FabianLars
Copy link
Member

We explicitly removed all variables from the API in v2 and stopped adding them to v1, because we got many many reports about issues with ssr-first frameworks (nextjs, nuxt, sveltekit, etc) because of variables (because they need access to the navigator or window variable).

I'm not ruling it out, just warning you that this is pretty unlikely as of now. As an idea for exploration, instead of using the typical ipc, using eval/init_scripts may work (with the caveats it has).

@amrbashir
Copy link
Member

amrbashir commented May 20, 2024

We can't break the API in v1 so I will just consider v2 for this issue and transfer the issue to plugins-workspace.

we can't make them constants, as Fabian said, will need to access window or navigator variables and will make issues in SSR frameworks, but we can make these functions not async at least, you will also be able to directly access them using window.__TAURI_OS_PLUGIN_INTERNALS__.eol if you prefer but I wouldn't rely on these internals.

@amrbashir amrbashir transferred this issue from tauri-apps/tauri May 20, 2024
amrbashir added a commit that referenced this issue May 21, 2024
…nd `exe_extension` functions sync

closes #1351
@FabianLars FabianLars added enhancement New feature or request plugin: os labels May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request plugin: os
Projects
None yet
3 participants