Finally, you jumped on the bandwagon of web components! Congrats! 😆
Web Components are going to solve ALL your troubles with CSS, Frameworks and Life... not really... right? 😏 What about stores? Immutable data? 😨 And all the other buzzwords? Just forget about them! 😵 VanillaJS Web Components is all you need, since the architecture to make them work for complex applications is already there. It is called the DOM and it is Event Driven. 😄
An Event Driven Architecture makes stuff like stores obsolete. Your components react on events and if they need something, they emit their event to ask for it. Sure, at this level you are free to decide, if you want to cache certain events, fetches, etc. or if you just want to fire and forget. We chose to simply cancel ongoing fetches at some endpoints (https://github.com/mits-gossau/event-driven-web-components-realworld-example-app/blob/master/src/es/components/controllers/Article.js#L81) but not all those approaches require any difficult logic anymore. Why should you even try to bloat your frontend with a bunch of business logic, if you have an endpoint with that logic already implemented? Keep it simple! 🤯
Even more important is to keep the process of using Web Components simple. They already bring everything you need with them and if something is missing you can extend your Web Component with some convenient setters and getters, a mutation observer and even an intersection observer: https://github.com/mits-gossau/web-components-cms-template/tree/master/src/es/components/prototypes
The death of IE11 made any transpiler redundant. 🥳 BUUUUUT what about TypeScript? Yes, also the TypeScript transpiler just puts additional complexity to your project, which you can spare yourself the trouble with: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html JSDoc Types nearly do everything you can wish for but do not enforce additional dependencies on you, if you already work with VSCode, it works out of the box. And yes, I love type highlighting!
The next of your concerns may is the loading of the Web Components. For an SPA it is simple, just load them when required: https://github.com/mits-gossau/event-driven-web-components-realworld-example-app/blob/master/src/index.html In case of server side rendering, you could ether have the backend template engine decide what to render when, although my backend colleagues are not very keen dealing with JavaScript, so I wrote a simple loader script for them: https://github.com/mits-gossau/web-components-cms-template/blob/master/wc-config.js the only disadvantage is, that you likely loose couple milliseconds for the request to the wc-config.js 🚽 plus some more milliseconds to load the required Web Components. In case you need a Lighthouse score of 100 you better just render those Web Component Classes straight into your html file but I think the convenience is worth the price of losing a few milliseconds. This is anyway, what you at least save by not loading and interpreting a framework. 😄
Conclusion, it is worth to look into the nature of the DOM, an Event Driven Architecture, once you feel ready to start working with Web Components. This will make a lot of classical complexity nonessential and keeps your application easy, simple, scalable and reusable.
The Real World Example of an Event Driven Architecture: https://github.com/mits-gossau/event-driven-web-components-realworld-example-app
The TodoMVC Example of an Event Driven Architecture: https://github.com/mits-gossau/event-driven-web-components-todomvc-app
Related Video Tutorials
https://weedshaker.github.io/event-driven-web-components-tutorial/src/#/one
Top comments (0)