Improve naming of our exports and consuming the exports about primitives HOT 8 CLOSED

Just had a play with styles concept because we need the styles to be "toString"able for our static style extraction and the data attributes and this seems to work well: https://codesandbox.io/s/staging-flower-nhm3w

It actually feels much nicer than what we currently have on our side.

from primitives.

considering individual parts are no longer tree-shakable

Oooo, interesting! Maybe we could test one of our larger components. One test with tree-shakable exports and another with dot notation to see if the difference is really that significant ?

Given that we're moving cssResets into its own package, our styles will only contain functional styles and I'm thinking most of the time consumers would need/want to use these?

from primitives.

So perhaps we should already export them named like this, seeing that people will build on top and most likely call it the same.

Yep I agree, I brought this up before and I'd guess many consumers building component libs will wish for the same.

from primitives.

From a DX perspective I think I agree -- the static property is quite nice!

For smaller components I don't think this matters all that much, but for larger components with more logic and complexity are we potentially designing ourselves into a box with this pattern, considering individual parts are no longer tree-shakable? I've actually been wondering if we might move back in the other direction to favor individual exports for that reason alone. 😬

from primitives.

Oooo, interesting! Maybe we could test one of our larger components. One test with tree-shakable exports and another with dot notation to see if the difference is really that significant ?

I'd love to see this before we release! I think most components we have right now are probably OK because all of the parts are pretty much required anyway. But in a select, you may or may not want Select.OptionCheckbox or Select.OptionRadio but we're giving you all of that code anyway. I could see something like a datepicker getting really wild.

from primitives.

I'm confused about the tree-shakability because generally the parts are not optional.
There might be the odd one but generally it's not the case. So the cost is there regardless.

I think most components we have right now are probably OK because all of the parts are pretty much required anyway. But in a select, you may or may not want Select.OptionCheckbox or Select.OptionRadio but we're giving you all of that code anyway. I could see something like a datepicker getting really wild.

Just saw that now… haha, yeah 🤔

from primitives.

Yeah this is less of a concern now than a potential concern that may come back to bite us if we want a consistent API 😬

from primitives.

Looks like we've covered all basis with this one now. I'll close but feel free to re-open if anyone thinks more attention is needed 😘

from primitives.