4 ms·
Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft
by zackbrown 4y ago
Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:
1. Conditional templating, like:
<SomeLayout>
if $is_android {
//Only render the back button for Android
<BackButton />
}
/* ... */
</SomeLayout>
2. Dynamic properties where Rust logic checks for the target platform, like:
<SomeElement some_property={self.get_platform_specific_value()} />
3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React Native
Or any mix of the above.
- zamadatix 4y agoDoes this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
- zackbrown 4y agoPax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs. That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas. This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html https://docs.pax-lang.org/intro-example.html
- zamadatix 4y agoThis could be very interesting, I'll have to keep an eye on the development. Thanks!