Expanding the available conditionals

[wrangelvid]

Creating responsive UIs with utilities like Tailwind's sm, md, lg, etc., is fantastic. However, UIKit can be even more powerful by allowing attributes to change based on whether a component is in an active immersive session. The use case is straightforward: when using UIKit to render a button in an immersive session, you might want to increase the hit-box and font size compared to a standard web view. This issue aims to discuss the implementation of this feature.

[wrangelvid]

One proposal is to name the attribute xr, ar and vr. Detecting the respective modes will call the specified styles.

[bbohlender]

Very interesting proposal. I was thinking the same for performance. E.g. highp, ...? to declaratively express different properties for low, mid, and high performance devices (e.g. material class, ...).

The problem with xr, ... I see is that I dont want to mix xr into uikit. Maybe we can come up with a nice syntax that allows to declare any conditional based on a custom signal.

[wrangelvid]

Very interesting proposal. I was thinking the same for performance. E.g. highp, ...? to declaratively express different properties for low, mid, and high performance devices (e.g. material class, ...).

I like that! However, who and how would decide what constitutes a low, mid, or high-performance device? With so many devices out there, maintaining an updated list that adjusts conditionally based on the device could become cumbersome. Alternatively, live benchmarking could be used, but that might be resource-intensive. Overall, I do like the idea of distinguishing between device performances.

Another idea: Dark mode.

The problem with xr, ... I see is that I dont want to mix xr into uikit.

I did some digging and understand what you mean. It's quite hard to distinguish between vr and ar mode without some elaborate state management solution. However, if we only check for xr, we could get away with getting the XR manager in the renderer and asking for the camera length.

Maybe we can come up with a nice syntax that allows to declare any conditional based on a custom signal.

That’s neat! We could implement that regardless. For example, a user could define different conditionals for different level styles. However, for conditionals that are widely implemented, it might be more convenient to support them natively. From what I understand, a large user base is trying UIKit in immersive applications, so making that conditional widely available could be useful.

[bbohlender]

@wrangelvid dark already exists ;-)

What about some kind of plugin system that can modify the types and the behavior for conditionals. That way once somebody implements a nice live benchmarking library, they can make that available for uikit, as well as the xr library can make the ar and vr conditionals available without requiring any specifics in uikit :)

[wrangelvid]

dark already exists ;-)

Awesome :)

I like that. natuerlich or react-xr could provide the plugins via a ConditionalProvider. Are you thinking about something like this?

<ConditionalProvider onConditional={checkIfInXRSession} conditionalName="xr">
<Container padding={4} xr={{padding:12}}>
...
</Container>
</ConditionalProvider >

[bbohlender]

I'd expose a global API because adapting the types for the conditions would happen globally, too, since we cannot change types inside a context.

e.g.

import { createConditional } from "@react-three/uikit"

const conditionalXR = createConditional("xr")

function toggleXR() {
 conditionalXR.set(conditionalXR.get())
}

(this just demonstrates the conditional API, I am not trying to say toggleXR would be a good idea :D)

[wrangelvid]

Awesome! That way we can even "toggle" existing conditionals in a alternative ways. That could be useful in testing/debugging for other existing conditionals. Oh would even allow turning the dark mode in a settings page without having to change the systems dark mode :)

[bbohlender]

setPreferredColorScheme("light") https://docs.pmnd.rs/uikit/getting-started/components-and-properties#preferred-color-schemes ;-)

but yeah :)

would you like to work on a PR for that (since I am focussing on the XR rewrite I wont get to this proposal for at least the next week)

[wrangelvid]

setPreferredColorScheme("light")

Damn it Bela, I should stop dreaming and read the docs 🤣

I'll give it a shot.