Implement shorthand syntax for spacing and backgroundColor

[META-DREAMER]

Its much nicer/cleaner to write out the spacing props in shorthand. This syntax is used in many similar projects that follow the system-ui spec.

[JoelBesada]

From my own experience, I agree that having these shorthands can be very comfortable once you get used to them. It was a conscious decision however to not include these in Restyle, since it goes against the variable / parameter naming best practices we have at Shopify. We generally want to use clear naming conventions and avoid non-standard acronyms.

I'll bring this up as a discussion point with the team, but would you consider rewriting this as something that can be opted in to? I think this could be broken up into a separate shorthandedSpacingProperties and shorthandedBackgroundColorProperties, and perhaps with a parameter in createBox and createText for opting in to adding them.

[META-DREAMER]

From my own experience, I agree that having these shorthands can be very comfortable once you get used to them. It was a conscious decision however to not include these in Restyle, since it goes against the variable / parameter naming best practices we have at Shopify. We generally want to use clear naming conventions and avoid non-standard acronyms.

I'll bring this up as a discussion point with the team, but would you consider rewriting this as something that can be opted in to? I think this could be broken up into a separate shorthandedSpacingProperties and shorthandedBackgroundColorProperties, and perhaps with a parameter in createBox and createText for opting in to adding them.

@JoelBesada What if you just separate the types instead? That way if you don't want shorthand props, it can be excluded on the type level so you get errors when they get passed in. Otherwise the dev experience takes a hit for something like createText if we add it as a param since the user is then forced to pass in the Text component just so they can pass in the enableShorthand component.

I would think that most users would want to enable the shorthand and that it should be the default. For anyone that wants to disable it, they can opt-out via the types. For example:

export type TextProps<Theme extends BaseTheme,  EnableShorthand extends boolean = true> =
  ColorProps<Theme> &
  OpacityProps<Theme> &
  VisibleProps<Theme> &
  TypographyProps<Theme> &
  SpacingProps<Theme> &
  TextShadowProps<Theme> &
  VariantProps<Theme, 'textVariants'> &
  (EnableShorthand extends true ? SpacingShorthandProps<Theme> : never);

[META-DREAMER]

Updated the PR, lmk what you think

[JoelBesada]

This seems to be causing problems, see:

Replacing never here with Record<string, never> seems to work well though.

[JoelBesada]

@JoelBesada What if you just separate the types instead? That way if you don't want shorthand props, it can be excluded on the type level so you get errors when they get passed in. Otherwise the dev experience takes a hit for something like createText if we add it as a param since the user is then forced to pass in the Text component just so they can pass in the enableShorthand component.

I would think that most users would want to enable the shorthand and that it should be the default. For anyone that wants to disable it, they can opt-out via the types

I can agree on letting the shorthands be enabled by default, and letting anyone opt out via the types. The dev experience for opting out becomes a bit cumbersome with this approach though, since you'd need to pass in React.ComponentProps<typeof View> & {children?: React.ReactNode} as the second type argument to set the third as false. I can live with it for now though if it can't be solved without breaking backwards compatibility.

[META-DREAMER]

@JoelBesada What if you just separate the types instead? That way if you don't want shorthand props, it can be excluded on the type level so you get errors when they get passed in. Otherwise the dev experience takes a hit for something like createText if we add it as a param since the user is then forced to pass in the Text component just so they can pass in the enableShorthand component.
I would think that most users would want to enable the shorthand and that it should be the default. For anyone that wants to disable it, they can opt-out via the types

I can agree on letting the shorthands be enabled by default, and letting anyone opt out via the types. The dev experience for opting out becomes a bit cumbersome with this approach though, since you'd need to pass in React.ComponentProps<typeof View> & {children?: React.ReactNode} as the second type argument to set the third as false. I can live with it for now though if it can't be solved without breaking backwards compatibility.

True, although that wouldn't be as big of an issue when #19 is addressed.

[JoelBesada]

LGTM

[smontlouis]

This is amazing, I'm a chakra-ui / styled-system / theme-ui addict I was hoping to have those shorthands props !