browser-window
github-elements
browser-window | github-elements | |
---|---|---|
1 | 14 | |
244 | 2,643 | |
- | 0.4% | |
8.1 | 0.0 | |
5 months ago | 5 months ago | |
JavaScript | 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.
browser-window
-
Web Fundamentals: Web Components Part 2
This covers all but one of the lifecycle methods that you get access to with custom elements, and in actuality, these are what you'd use most of the time. The last one is adoptedCallback and you'd most likely encounter it in the context of elements [4]. Even though I don't have plans to go through it in the series, the concepts and the way we've covered them so far should give you a good idea on how to begin unpicking it if you do. Other than that, we have enough under our belt to delve even deeper into what web components have to offer.
All of this might feel like a lot of work to put some HTML on the screen and update a few attributes, and it is. Even though we've achieved fine-grained updates in our component, it took a fair bit of reasoning about the lifecycle methods to get there. The reason the custom elements API feels a little cumbersome is because it's low level by design to give you the most control. This means that you can do anything with it, including build your own abstractions on top of it.
There are other component-based abstractions that will give you the same effect with a lot less work, and some even give you the same level of fine-grained control. Though we'll look at a few UI frameworks alongside web components, the ultimate aim of this series is to demonstrate what the web platform is capable of, and get you to start thinking about the different tradeoffs you make when picking different tools. My hypothesis is that by understanding what the platform has to offer, you'll be in a much better position to evaluate the complexity you choose to take on when building experiences. Lastly, I'll leave you with a little spoiler of what's to come: web components are cool and they are here to stay.
If you think of anything I've missed or just wanted to get in touch, you can reach me through a comment, via Mastodon, via Threads, via Twitter or through LinkedIn.
References
- Zach Leatherman's
component [GitHub]
- MDN Web Components [Website]
- Component Lifecycle Reference Diagram [Website]
- Component Lifecycle Reference [Website]
- Zach Leatherman's
github-elements
-
What Web Frameworks Solve And How To Do Without Them
Take a look at github's web components: https://github.com/github/github-elements it's similar. There is no library there, it's just a collection of separate components, the only difference there is that their collection is split into different github repositories, I could have done the same, but I chose to put them all into the same github repository.
-
🧢 Stefan's Web Weekly #18
github/github-elements – GitHub's Web Component collection.
-
We Should Stop Hating Web Components
Github uses a set of custom elements called Github Elements
-
5 Github Elements you have to try
There are lots more elements to take a look at so check the whole repository and examples here.
- GitHub's Web Component collection.
- GitHub's Web Component Collection