soci-frontend
community-protocols
soci-frontend | community-protocols | |
---|---|---|
4 | 8 | |
19 | 168 | |
- | 0.0% | |
0.0 | 5.4 | |
9 months ago | 23 days ago | |
JavaScript | ||
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
soci-frontend
-
Using SVG to create simple sparkline charts
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
-
We Use Web Components at GitHub
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...
-
Add a Dark Theme to a Ruby on Rails App
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.
community-protocols
-
What We Need Instead of "Web Components"
> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem
Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal.
(In the meantime, the Observable primitive from rxjs been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2].
So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-)
0 - https://github.com/webcomponents-cg/community-protocols/issu...
1 - https://github.com/WICG/observable
2 - https://nitter.net/BenLesh/status/1737174784406933599
-
Show HN: Hyphen – custom element base class for good ergonomics
The custom element spec definitely only deals with the mechanics of when are where to run your component's lifecycle code - it says nothing about data. So your choices are basically property accessors, which are interoperable, but require prop-drilling for global-ish data, or something proprietary like a state management library.
The Web Components Community Group (WCCG) is offering something of a third way with the community protocols: https://github.com/webcomponents-cg/community-protocols
The Context protocol provides tree-scoped ambient data in an interoperable way. It's implemented by Lit and FAST (I believe). It doesn't replace a data store, but it's often used to provide data stores to components, and at least reduce some coupling.
-
Events are the shit
Did you know events can also carry promises? A great showcase of this pattern is the Pending Task Protocol by the Web Components Community Group. Now, "Pending Task Protocol" sounds very fancy, but really, it's just an event that carries a promise.
-
Nx Console gets Lit
If you’re coming from the Angular world, you probably appreciate the great dependency injection (DI) mechanism they have. You can centrally define some services and reuse them across your app, without thinking about passing on props from component to component - the DI system takes care of it. Lit provides something similar via the [@lit-labs/context](https://lit.dev/docs/data/context/) package. It’s based on the Context Community Protocol and similar to React’s context API.
-
Back to the Front-end: Exploring the Future of the Umbraco UI (Part 9 - Context API)
Fundamentally it is an event based mechanism to access state or "context" from ancestores of a component node. Based on the Web Components Context Protocol RFC which in turn is inspired by React's Context Api, the key purpose is to solve the problem of prop drilling.
- 🕎 8 Days of Web Components Tips
-
JavaScript vs JavaScript: Round 2. Fight!
The conversation led to the creation of https://github.com/webcomponents-cg/community-protocols. So there is some effort to standardize at least on convention for these higher-order considerations, but working through this and how opinionated it is made me recognize even more that this has a lot of similarities to a different group building a different framework. Tricky balance.
-
We Use Web Components at GitHub
I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange.
However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface.
In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.
What are some alternatives?
Stimulus - A modest JavaScript framework for the HTML you already have
web3-sign-msg - web3-sign-msg is a modern web component built with ficusjs to sign messages with your eth private key in Metamask
services-as-dom-elements
vscode-webview-ui-toolkit - A component library for building webview-based extensions in Visual Studio Code.
view_component - A framework for building reusable, testable & encapsulated view components in Ruby on Rails.
React - The library for web and native user interfaces.
ficusjs - FicusJS is a set of lightweight functions for developing applications using web components
nx-console - Nx Console is the user interface for Nx & Lerna.
open-wc - Open Web Components: guides, tools and libraries for developing web components.