6 ms·

I (alongside some very talented people) work on this. AMA!

by chrislloyd 9y ago

danielvf 9y ago
Chris, the docs are fantastic!
- chrislloyd 9y ago
  Thanks! It's been a big group effort. We've put a lot of work into them (with much more to come) and they've massively helped Gestalt's adoption in both the eng. and design orgs.
mjdude 9y ago
Congrats on getting this released! Does it support theming? Took a quick look at the docs I don't think it does.
- chrislloyd 9y ago
  Not currently, though this is a question that gets asked a lot. One of the benefits of Gestalt is that all styling is statically resolvable. This means that all it's CSS can be built to one small file or inline styles. We get a bunch of perf. & portability for free. (Unconstrained) theming requires runtime style resolution which would negate those benefits. There are also things that we'd like to be able to change and tweak globally and those get difficult if everybody is running separate themes. We recently switched to using system fonts and we're planning on bumping the color contrast. However, we're generally _really_ open to constrained theming (i.e. more button colors).
  - mjdude 9y ago
    Thanks for the explanation, that makes sense. Being able to change colours would go a long way in and of itself.
marklmc 9y ago
Awesome job! QQ- why declare typing in both flow and proptypes? Thanks!
- concerned_user 9y ago
  Because proptypes actually catch stuff during runtime, flow not so much. Maybe I have a wrong setup, but that is the case for me.
  - aviraldg 9y ago
    There's a Babel plugin that transforms your code to do runtime typechecks based on your Flow type annotations: https://codemix.github.io/flow-runtime https://codemix.github.io/flow-runtime
  - markl42 9y ago
    If you already have static type checking, is that not enough? Are there scenarios where proptypes will throw/show warnings at runtime that flow wasn't able to catch at build time?
- chrislloyd 9y ago
  Same as what other commenters have suggested, both runtime and compile time checks are useful. We'd like to consolidate around Flow (our docs specify flow types) but just haven't gotten around to adding/vetting that Babel plugin (or alternatives). I'd personally like to just use static types but it would mean that all users would have to use Flow + our specific version of Flow.
bobrenwick 9y ago
Out of interest, how many engineers worked on this internally, before the public release, and how long did it take?
xtalx 9y ago
This is a really nice piece of work! I’ve been experimenting with building something similar for my employer... I like that theming isn’t really a concern here. It makes sense because Pinterest already has a “theme” and this implementation enforces the theme. I have a few questions... These aren’t framed as “defend the choices that were made because I think they’re dumb” kind of thing, haha. I just think knowing some of the reasoning behind some of the implementation details would be illuminating. Why not use something like Glam or Emotion to handle className generation? With absolute positioning on <Box />... is there a reason why the top, bottom, left, right props are limited to static values of and not like top={48} or left=“12px” Also curious on api that dictates Text component: color = css property color and Box component: color = css property background-color Does Pinterest not use textShadow? Curious why that’s not a part of the Text component. Text styling seems to be the most difficult part of a component based design system. Anyway this is great work! Hopefully I didn’t ask any stupid questions with obvious answers. Ha

I (alongside some very talented people) work on this. AMA!

danielvf 9y ago

Chris, the docs are fantastic!

chrislloyd 9y ago
Thanks! It's been a big group effort. We've put a lot of work into them (with much more to come) and they've massively helped Gestalt's adoption in both the eng. and design orgs.

mjdude 9y ago

Congrats on getting this released! Does it support theming? Took a quick look at the docs I don't think it does.

chrislloyd 9y ago
Not currently, though this is a question that gets asked a lot. One of the benefits of Gestalt is that all styling is statically resolvable. This means that all it's CSS can be built to one small file or inline styles. We get a bunch of perf. & portability for free. (Unconstrained) theming requires runtime style resolution which would negate those benefits. There are also things that we'd like to be able to change and tweak globally and those get difficult if everybody is running separate themes. We recently switched to using system fonts and we're planning on bumping the color contrast. However, we're generally _really_ open to constrained theming (i.e. more button colors).
- mjdude 9y ago
  Thanks for the explanation, that makes sense. Being able to change colours would go a long way in and of itself.

marklmc 9y ago

Awesome job! QQ- why declare typing in both flow and proptypes? Thanks!

concerned_user 9y ago
Because proptypes actually catch stuff during runtime, flow not so much. Maybe I have a wrong setup, but that is the case for me.
- aviraldg 9y ago
  There's a Babel plugin that transforms your code to do runtime typechecks based on your Flow type annotations: https://codemix.github.io/flow-runtime https://codemix.github.io/flow-runtime
- markl42 9y ago
  If you already have static type checking, is that not enough? Are there scenarios where proptypes will throw/show warnings at runtime that flow wasn't able to catch at build time?
chrislloyd 9y ago
Same as what other commenters have suggested, both runtime and compile time checks are useful. We'd like to consolidate around Flow (our docs specify flow types) but just haven't gotten around to adding/vetting that Babel plugin (or alternatives). I'd personally like to just use static types but it would mean that all users would have to use Flow + our specific version of Flow.

bobrenwick 9y ago

Out of interest, how many engineers worked on this internally, before the public release, and how long did it take?

xtalx 9y ago

This is a really nice piece of work! I’ve been experimenting with building something similar for my employer... I like that theming isn’t really a concern here. It makes sense because Pinterest already has a “theme” and this implementation enforces the theme. I have a few questions... These aren’t framed as “defend the choices that were made because I think they’re dumb” kind of thing, haha. I just think knowing some of the reasoning behind some of the implementation details would be illuminating. Why not use something like Glam or Emotion to handle className generation? With absolute positioning on <Box />... is there a reason why the top, bottom, left, right props are limited to static values of and not like top={48} or left=“12px” Also curious on api that dictates Text component: color = css property color and Box component: color = css property background-color Does Pinterest not use textShadow? Curious why that’s not a part of the Text component. Text styling seems to be the most difficult part of a component based design system. Anyway this is great work! Hopefully I didn’t ask any stupid questions with obvious answers. Ha