This was bound to happen 😂 .

Here's how I've organized it in G2. It may spark some ideas!
https://github.com/ItsJonQ/g2/blob/master/packages/styles/src/theme/config.js

I think naming it something like config.js would be helpful. At the very least, it makes it feel more important/official (which it should be).

Since it's a JS object, you can group certain values together and ...spread them in the final object :).
That's how I've been keeping things tidy!

Lemme know what you think :D

Do you think we should group everything together like G2 does, moving font and config together into a single object? I'm not necessarily opposed to that 🤷‍♀️ I don't have any strong opinions here so just let me know what you think would be best (I've already renamed this to config rather than misc-variables).

From my experience, when you start having LOTS of variables, it's quite nice to have it somewhat centralized.

It being a flat object vs. nested is subjective, although I've found a single flat objected being easier to work with.

We don't necessarily have to do this to start :). Just wanted to share some thoughts!
The current setup works okay 👍 .

I especially like how you're developing a pattern around accessing values via some sort of function.
It's a workflow that's shared between breakpoint(), font(), color(), and now config() :)

👋 @saramarcondes I'm curious about these changes and what motivated them…

Other "values" utilities use nested objects, e.g.

color( 'blue.wordpress.700' );

These rely on lodash get's string object-path-like property access (get( { foo: { bar: 'baz' } }, 'foo.bar' )). In this case, it looks like the object-path-like strings are used directly as the keys. This was a bit surprising to me 🙂

That's not necessarily a bad thing! it's just inconsistent and the keys here like helpText.fontSize were surprising to me.

We may be able to move away from get and rely more on TypeScript to ensure we're accessing values that exist.

My intention was to keep things type-check-able! get obscures everything, the way I’ve set things up you get nice autocomplete. I chose to namespace values using the dot notation to match that nice feature from the colors utility while still getting the typecheck benefits.

Is it possible for us to maintain a typechecked “getter” function while having truly nested objects?

Just to be clear, I think this direction is great but we can go farther 🙂

My intention was to keep things type-check-able! get obscures everything

get will actually do a pretty good job (it's definition is interesting to look at), but JS/JSDoc is likely hindering it. Type arguments don't seem to work as well 😢

Is it possible for us to maintain a typechecked “getter” function while having truly nested objects?

I'm confident we could do a couple of levels of nesting without much trouble. Arbitrary depth is at least more complicated (we'd probably take inspiration from get)

However, we know statically everything about these objects! What purpose does the getter serve? We swap parens for braces and we have the same behavior.

const fontSize = font( 'helpText.fontSize' );
const fontSize_ = FONTS[ 'helpText.fontSize' ];

If we want nested objects and we accept that a getter isn't necessary (it may be, please convince me) then we just access them the . notation and can get excellent type support:

Here's a playground link with some of this set up already.

Certainly, we could just access the object directly and that would work fine. However @ItsJonQ has some good rationale for a "getter" function laid out here: https://g2components.wordpress.com/2020/10/23/creating-a-variable-system/

Because of that we have some limitations as to what information we can give to TypeScript, at least that's my understanding. The definition for get you linked is indeed interesting, however it only works if you split the path into segments rather than using a the dotted notation, which is already prevelant in the codebase for the existing getter functions.

Given those limitations and given that we probably want to be able to namespace things, I did the best with what I had... perhaps there's still something I'm missing that would allow us to avoid this style of namespacing while keeping the getter functions?