Hacker News Reader

Comment by chrislloyd | Hacker News Reader

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

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

Awesome job!

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

Because proptypes actually catch stuff during runtime, flow not so much. Maybe I have a wrong setup, but that is the case for me.

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

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?

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.

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

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).

Thanks for the explanation, that makes sense. Being able to change colours would go a long way in and of itself.

Chris, the docs are fantastic!

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.

Reply on news.ycombinator.com