browser-window
vue-custom-element
browser-window | vue-custom-element | |
---|---|---|
1 | 4 | |
244 | 1,954 | |
- | - | |
8.1 | 1.2 | |
5 months ago | about 1 year 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
vue-custom-element
-
SSR support for Web Components
Do You think that WebComponents wrapping React/Vue components (e.g. https://github.com/karol-f/vue-custom-element) could use it?
- Is this a good way to use Vue for only creating UI components in Laravel?
-
Migrating a React codebase to web components
Example implementation of that docker-like approach is e.g. https://github.com/karol-f/vue-custom-element
- Using Vue in Laravel MPA
What are some alternatives?
web-skills - A visual overview of useful skills to learn as a web developer
inertia-laravel - The Laravel adapter for Inertia.js.