services-as-dom-elements VS soci-frontend

Would love to see why they did not choose lit-element, it was one of the best I tried in a recent experiment of ~5 solutions.

The big thing holding back webcompinents at this point is a data sharing strategy, and I think we could get away with actually using components to store and manage data:

https://www.vadosware.io/post/sade-pattern-services-as-dom-e...

The github repo (which also happens to contain how to write a web component in lit-element, slim.js, tonic, vue, svelte):

https://gitlab.com/mrman/services-as-dom-elements

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.