I wanted to have a simple polished open source app that treats code as first class; nothing fancy like an LSP but just a little bit of syntax highlightin would be nice.
Initially, I tried to hack up something here ⇒ https://github.com/ruinivist/excalidraw-box but this just became a cancerous project with absolutely positioned stuff, patches directly on excalidraw lib, and still far from what I wanted. Tldraw seemed like another nice alternative but it’s license it tooo restrictive. There’s a couple more but nothing quite fulfill what I wanted so here we are.
The rest of this serves as some design decisions on systems.
What should an opinionated foundational ui library contain?
The question is, should it manage typography and colors and to what extent. How should the usage tie tothether, do YOU maintain the theme and then just pass it as args all the way or should the lib define a theme and read from there. Should I have used Google’s theme tokens ( I find them a bit too verbose and hard to use especially for typography )?
Let’s take them one by one.
If the library enforces a defaul typgraphy, it’ll almost always be overriden ( no one wants YOUR font ), at best you can enforse some sizing and styling but I think the cleaner idea is to expose a typography theme which has semantic tokens and then a customization would give you a coherent idea of what the library author wanted the meaning of components to be ( a title remains title after all )
The same can be said for colors as well, so extracting into semantic colors + allowing overrides at widget level would be the ideal way to go definitely.
Should I use google’s tokens? For typography, no, they define 15 tokens with a variation of small, medium and large. Display, headline and title are three different tokens with similar sounding names. That is too much of bloat; I think they just wanted to cover every case under the sun epsecially being cross platform.
I have a much more favorable view of the color system though, still it does have more colors that it should — each token is a cognitive load on the understanding of the design.
I do think though that I should have adapters that convert to my library’s theme system which will be some subets of the google’s tokens; it’ll arrogance on part of a library creator to think their system is better and to expect people to ditch everything and use what them make. Compatibility would be the right way here.
An update on themes
I don’t intend to use material, not their colors not their styling, so trying to PATCH in my widgets to use that is the wrong direction. I should only provide a color scheme and typography for not yet customized widgets and NOT the other way around, I do not carry burden or overhead of some vague notion of compatibility, when re-inventing makes sense here because it’s not the same thing.
I also reverted my decision of making the foundation widgets generic and plumbing args at call site, that is just bad design unless you are making a framework which I’m not. It’s very easy for the args and hence the renders to differ which defeats the whole purpose of a “foundation” widget anyways — might as well use native and plumb args there, you see the problem.
Also, there should be no arg based override too by default, YAGNI, plus not having an arg makes having local overrides ( again theme drift ) harder to add, giving you a moment to pause and reflect if this is even needed, you can always add an arg as and when needed.