Unifies Box/Flex

[dzucconi]

Picking up on the initial impetus behind #704

We might have a few minor issues surrounding the flexGrow/Shrink props (which are now required to be numeric). I noticed that since size was being passed to the underlying Flex in Avatar, that was causing an issue because space ships with a size mixin which sets width/height. Maybe we just remove that, actually?

📦 Published PR as canary version: 10.1.1-canary.707.11364.0

✨ Test out this PR locally via:

npm install @artsy/palette@10.1.1-canary.707.11364.0
# or 
yarn add @artsy/palette@10.1.1-canary.707.11364.0

[dzucconi]

Ah, I see that also hits the Typography component.

I'm also thinking we can dramatically simplify that once we fix the font declarations so, maybe that's up next.

[zephraph]

verticalAlign is included in the new layout helper which we should use instead.

The layout utility includes style props for width, height, display, minWidth, minHeight, maxWidth, maxHeight, size, verticalAlign, overflow, overflowX, and overflowY.

https://styled-system.com/api#layout

[zephraph]

(Likewise, a lot of the other props can be replace with typography )

https://styled-system.com/api#typography

[dzucconi]

So, I figured I'd update Typography on it's own because it can mostly go away with fixing the font-face declarations.

[zephraph]

I think the type failures that you're getting here is what I was discussing with Orta.

The keys for the typesizes in the theme file are defined as "1", "2", etc but get simplified to 1, 2, etc automatically by TS. I'm not sure exactly what to do about that yet.

[zephraph]

My questions have been answered, so 👍 from me.

Once the type errors have been fixed, feel free to merge.

[dzucconi]

Hm, ok yeah those errors are specifically related to TypeScript 3.9.3. Is that an actual bug?

We can maybe address this when we implement the new typography scale and work out a plan for deprecating the old styles (maybe convert them into non-numeric strings and leave it alone)

[zephraph]

From my conversation w/ @orta it sounded like it was intentional (because it's fundamentally equivalent to TS under the hood).

We could get around it by broadening the typography props to accept any string.

[orta]

oh cool - Damon's back, hiiiii

[damassi]

@dzucconi - so to be clear, this just collapses the shared code and you suggest we continue using <Flex> and <Box> for markup clarity, yah? Or just <Box>?

[dzucconi]

we continue using <Flex> and <Box> for markup clarity, yah? Or just <Box>

I don't think this matters much. I'd probably exclusively use <Box>. I suppose there's something to be said about components that are shared with iOS and having to exclusively use <Flex> for those?

[dzucconi]

So looking at force/eigen. There's 3 places in each that use the flexGrow="string" syntax which would no longer be supported. Simple fix to upgrade for each but technically this release would be a breaking change.

[artsyit]

🚀 PR was released in v11.0.0 🚀