Consider Size component

I’m wondering if there should be a Size component, whose explicit role is to let us size items consistently without using webContainerSx. I made something like it in my app, and I’m wondering if it should be included in Dripsy directly.

Examples

For flex columns:

import { Size } from 'dripsy'

<Row>
  <Size flex={[null, 1]}>
    <Column />
  </Size>
  <Size flex={[null, 1]}>
    <Column />
  </Size>
</Row>

For widths:

<Size width={['50%', '33%']} />

Why

At the moment, the same thing is achieved by passing a webContainerSx prop. It’s a bit cumersome and repetitive. I think it’s a nice escape hatch prop to have, but for sizing, it makes more sense to have a specific solution.

Since the entire sx prop would not be supported, style props would be inlined on the Size component.

Code

On native, it would export a View from dripsy, like normal (with added props.) Nothing special happening on native.

size.tsx

import View from './view'

type SizeProps = Pick<SxStyleProp, 'flex' | 'width' | ...etc>

const Size = (props: SizeProps) => {
  return <View sx={props} />
}

On web, however, we can render a native div, and use sx with the JSX pragma from theme-ui.

size.web.tsx

/** @jsx jsx */
import { jsx } from 'theme-ui'

const RNWStyleReset = {...}

const Size = (props: SizeProps) => {
  return <div sx={{ ...RNWStyleReset, ...props }} />
}

[nandorojo]

While I’m using this my app, I’m still not sure if I’m convinced by it. I think getting rid of SSR (and thus fresnel) would be a better idea than entirely circumventing RNW altogether 😕

[nandorojo]

Yeah, that’s true. Although I would recommend returning null (or a placeholder) and then rendering the app after it’s mounted if you ever plan on using responsive styles. I’ll probably do this with an ssr prop on the provider.

Ultimately, we’re dealing with constraints of RNW.