5 ms·

It does not answer the native styling though…

• 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 ago
    Does 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 ago
      Pax'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 ago
        This could be very interesting, I'll have to keep an eye on the development. Thanks!