view_component VS soci-frontend

When searching for examples of table components built with the ViewComponent gem, I was surprised to find none. After some inquiries, I came across examples that worked like this:

View components offer two primary ways to interact with the component: passing arguments to the initializer and using slots:

For example, splitting out views into partials? Or the new ViewComponent feature that's becoming quite popular - https://viewcomponent.org/

I used to do "pure ruby" approach to that -- but basically wound up realizing I was re-inventing github's view_component. Their design goals were similar enough to what I was trying to do, that it made more sense just to use that, rather than try to re-invent it myself.

ViewComponent

The linked one is my Rails implementation, written for ViewComponent. The official version uses Nunjucks.

I ended up hand crafting my svg graphs for non.io for many of the same reasons. I originally was looking around at 3rd party libraries, but one of my goals with the site was to use as few external libraries as possible. I made an attempt at dynamically generating the svg points myself, and found it incredibly easy.

For context, here's the 22 lines of code it took to create a simple svg graph: https://github.com/jjcm/soci-frontend/blob/master/components...

And here's the final output: https://non.io/Animation-example

CSS variables help somewhat with this. Variable values penetrate the shadowroot, so you can effectively build an "api" for styles your component. I've done that a few times, and it's been enough for me to get by in most cases. An example is here: https://github.com/jjcm/soci-frontend/blob/master/components...

This is excellent for a small app, but if you have any production sized app or a larger team, it's not a great approach. Using colors directly in a theme override mean you have to then design and write the css for every page twice.

A better approach for doing dark mode is to use semantic tokens as a middleman. This works great not just for dark mode, but theming in general - allowing for high contrast mode, color blind modes, and others, while reducing the amount of effort required to style a new page (rather than growing multiplicatively with direct overrides).

If you're curious about this, I have a very basic schema I made for my app that you're welcome to steal here: https://github.com/jjcm/soci-frontend/blob/master/docs/token...

Here's an example implementation of the above schema: https://github.com/jjcm/soci-frontend/blob/master/soci-token...

The great thing is once it's implemented, it becomes VERY easy to know what token to use where. Got a button that's a primary action in a hover state? You probably want to use --brand-background-hover for the bg. Means you can do a lot of the design directly in code I find.