DEV Community: weedshaker

Build an Event Driven TodoMVC App with 8 lightweight VanillaJS Web Components

weedshaker — Sat, 03 Jul 2021 14:31:31 +0000

Demo

First try out the TodoMVC App to get an idea what it is capable todo: https://mits-gossau.github.io/todomvc-app/examples/WebComponents/src/
Note about Browser compatibility: This example uses the attribute "is", which is not yet supported by IOS. It is possible to simply avoid this problem by wrapping elements with web components. As can be seen at our Real World Example.

HTML Overview

Starting at the todomvc-app-template and looking at it's HTML: https://github.com/tastejs/todomvc-app-template/blob/master/index.html respectively at the extended HTML with #attr-is tags: https://github.com/mits-gossau/todomvc-app/blob/master/examples/WebComponents/src/index.html gives us some idea of which elements are going to have logic:

the "input.new-todo" field is at the top of the application and emits the event new-todo with a value for creation of a new todo item.
the "section.main" holds the "input.toggle-all" and the "ul.todo-list" and must be hidden, if there are zero items. It listens to the event all-items to toggle between hidden and shown.
the "input.toggle-all" is the arrow facing down on the left hand side of the "input.new-todo". It emits the event toggle-all to toggle all items to checked or unchecked (completed or incomplete). It also listens to the event all-items to toggle itself checked or unchecked.
the "ul.todo-list" holds all todo items. It listens to item emitted events regarding: edit, toggle, destroy. It also listens to the events: new-todo (where it loads TodoItem.js and appends it as child), toggle-all, clear-completed. It emits the event all-items once things change and takes care of saving to the localStorage.
the "footer.footer" inherits the same web component as at entry 2. "section.main" does. It must be hidden, if there are zero items. It listens to the event all-items to toggle between hidden and shown.
the "span.todo-count" listens to the event all-items and counts accordingly.
the "ul.filters" listens to the global hashchange event and toggles it's selected class accordingly.
the "button.clear-completed" emits the event clear-completed and listens for the event all-items to toggle if it is hidden or shown.

The list above already holds a rough description of 7 out of 8 web components (element 2. and 5. share the same web component). The 8th web component is the TodoItem.js. This one gets created by the "ul.todo-list" and listens to the events toggle-all and the global hashchange. It emits toggle, destroy and edit (edit is a reuse of the new-todo web component and bubbles through the todo item web component).

Loading the Web Components

Loading web components is fairly straight forward.

import('./es/components/TodoList.js').then(module => ['todo-list', module.default, { extends: 'ul' }])

Import a JavaScript file. Then you receive the module object on which you find the class as module.default, as long as you also export it as default.

export default class TodoList extends HTMLUListElement {

Give it a node tagName and for the usecase of #attr-is add the option telling the DOM which exact HTMLElement it shall extend. This option must correspond with the class extends HTMLElement. All the imports can be wrapped into a Promise.all and then we throw it at customElements.define. Now our seven nodes are hooked with the web component classes. The TodoItem.js is going to be loaded by the TodoList.js as soon as it is required, eg. there is an actual entry/item.

Event Driven

An event driven architecture means that these web components are only communicating through events. The only two exceptions are found at TodoList.js, when it loads the TodoItem.js and passes the value to the constructor:

this.appendChild(new TodoItem(event.detail.value))

as well as at the TodoItem.js itself, when it loads NewTodo.js for it's editing input field. Then it passes a few attributes to the web component:

<input class="edit" value="${this.value}" is="new-todo" new-todo="edit" allow-empty allow-escape>

The beauty about events is:

the components are independent
nice overview on what they listen can be found at the connectedCallback
FireFox DevTools let you inspect the event listeners
reusable web components
scaling to large size architecture
using same architecture as the DOM itself
no dependencies/frameworks required => pure standard
simple to use
state management is obsolete
super fast and greatly lightweight:

Overview of each Web Component

1. the "input.new-todo" gets NewTodo.js applied to it.

connectedCallback () {
  this.addEventListener('blur', this.valueListener)
  this.addEventListener('keyup', this.valueListener)
}

All the logic this component holds is inside the valueListener, which basically has a few flags, some decide upon the received attributes, when to dispatch the event 'new-todo'. The 'new-todo' event can also be renamed by passing an attribute called "new-todo" and is used as such at the TodoItem.js, which makes it dispatch the event 'edit' instead of 'new-todo'.

2. the "section.main" gets NoItemsHidden.js applied to it.

connectedCallback () {
  self.addEventListener('all-items', this.allItemsListener)
}

The allItemsListener holds the logic for this web component. It sets hide=true when the allItemsListener event.detail.items.length is falsy.

3. the "input.toggle-all" gets ToggleAll.js applied to it.

connectedCallback () {
  this.addEventListener('click', this.clickListener)
  self.addEventListener('all-items', this.allItemsListener)
}

The clickListener listens to the input checkbox being clicked and emits the event 'toggle-all' with the boolean checked as event.detail. It also listens with the allItemsListener to the 'all-items' event. There it decides, if it is still checked or not.

4. the "ul.todo-list" gets TodoList.js applied to it.

connectedCallback () {
  this.addEventListener('edit', this.updateListener)
  this.addEventListener('toggle', this.updateListener)
  this.addEventListener('destroy', this.updateListener)
  self.addEventListener('new-todo', this.newTodoListener)
  self.addEventListener('toggle-all', this.toggleAllListener)
  self.addEventListener('clear-completed', this.clearCompletedListener)
  this.loadAllItems().then(() => this.dispatchAllItems())
}

It listens to the events 'edit', 'toggle', 'destroy' emitted by it's child component TodoItem.js, which indicates that something on the items list changed and shall be propagated through dispatching the event 'all-items'. The same plus a little extra logic is executed at 'toggle-all' and 'clear-completed'. It also creates new TodoItem.js on the event 'new-todo'. At the updateListener it also saves the changes to the localStorage, which gets loaded on connectedCallback.loadAllItems.

5. the "span.todo-count" gets TodoCount.js applied to it.

connectedCallback () {
  self.addEventListener('all-items', this.allItemsListener)
}

It listens to the event 'all-items' and does update it's innerHTML accordingly to the latest count.

6. the "ul.filters" gets TodoFilters.js applied to it.

connectedCallback () {
  self.addEventListener('hashchange', this.hashchangeListener)
  this.hashchangeListener()
}

It listens to the global 'hashchange' event and updates it's selected CSS according to the global route.

7. the "button.clear-completed" gets ClearCompleted.js applied to it.

connectedCallback () {
  this.addEventListener('click', this.clickListener)
  self.addEventListener('all-items', this.allItemsListener)
}

The clickListener listens to the button being clicked and emits the event 'clear-completed'. It also listens with the allItemsListener to the 'all-items' event. There it decides, if it is hidden or shown.

8. the TodoItem.js gets loaded by TodoList.js when loadAllItems loads from localStorage or at the event 'new-todo'.

connectedCallback () {
  if (this.shouldComponentRender()) this.render()
  this.hashchangeListener()
  this.addEventListener('input', this.inputListener)
  this.addEventListener('click', this.clickListener)
  this.addEventListener('dblclick', this.dblclickListener)
  this.addEventListener('edit', this.editListener)
  self.addEventListener('toggle-all', this.toggleAllListener)
  self.addEventListener('hashchange', this.hashchangeListener)
}

The event 'input' applies to the checkbox and dispatches the event 'toggle' checked. The event 'click' applies to the delete button and dispatches the event 'destroy'. The event 'dblclick' sets the class editing. The event 'edit' is dispatched and bubbles further up by it's child input field NewTodo.js. The editListener then applies the new value. The event 'toggle-all' sets itself checked or unchecked. The global event 'hashchange' decides if this todo item shall be hidden or shown. The hashchangeListener is also triggered at the connectedCallback as well as at the inputListener, when it's own checked status changes.

ShadowDOM and encapsulated CSS

You must have encountered the term ShadowDOM and it's fabulous feature to encapsulate CSS. The TodoMVC App Template already delivers a global CSS. In this spirit, it made no sense to break out CSS and encapsulate it into the web components. But I have some examples where we use this feature:

It is certainly what sets it apart of all other approaches and is worth a separate article how to newly deal with CSS in this new environment.

Conclusion

I hope this gave an overview about the https://github.com/mits-gossau/event-driven-web-components-todomvc-app and how you could build it. I believe that an event driven architecture is the future of all frontend stacks/applications as well as it is often already applied under the hood of some framework logic, which could be redundant, if you learn how to immerse into the DOM.

Web Components and now what?

weedshaker — Mon, 14 Jun 2021 11:25:57 +0000

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

DOM and the event driven architecture - Introduction

weedshaker — Thu, 09 Jul 2020 13:16:41 +0000

At times of IE6 we were exited to have a primitive console. 📺 Later came firebug bug 🔥🐜 and libraries like JQuery, which made it possible to easily navigate different web api implementations by browser vendors. While those issues started to be harmonized out of our ways (thank you W3C) compilers solved modularity and frameworks like react or angular solved state management/single page app and DOM concerns. And while all this was happening Macro Medias Flash with it’s powerful Action Script was mercilessly assassinated. 🔫😢

Today, our web api’s reach a depth, which Action Script delivered in 2005 🥳 . At the same time our laziness and division about frontend technology has not only created a uniform, uncreative appearance by bootstrap and material UI. But opened the JavaScript, HTML and CSS stack for discussion by wasm (rust, .net, C++) solutions.

In general I see wasm as an enrichment of JavaScript but others see it as the end of such. This prediction is going to full fill, the more divided the frontend dev camps become. React vs. VueJs vs. Ember vs. Angular vs. etc etc. The only huge savior of JavaScript is by adopting the won learnings out of such frameworks and start using W3C web components with VanillaJS. #useWebApi !!! 🔨😎🤙 and wake up to the fact that the W3C standard, tc39 (ES6) solved most past and future concerns. Since IE11 died ⚰️, we can use the fancy 🦄 stuff anywhere without polyfills nor webpack, nor framework only one thing to learn: https://developer.mozilla.org/en-US/docs/Web/API

Finally, things are becoming simple again. 🤪 But then you will ask me how to solve your applications state management? My answer is “When in Rome, do as the Romans do”. Your application is in the DOM so do as the Domans do! How does the DOM do? The DOM is event driven and CustomEvents is a standard https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent, by which your web components https://developer.mozilla.org/en-US/docs/Web/Web_Components will be communicating. ShadowDOM, event driven web components, asynchronicity and http2 are so much optimized that your site feels as fast as a static site and at the same time let’s you make it static, if desired and hydratable by the nature of web components. 🌊

Your time to interactivity is going to be lower than ever before. No more threat blocking code! 🆘🔨

Web components are a perfect match for complex single page apps with reusable components, micro frontends on static pages and at the same time flexible enough for any other use case running in or on the DOM.

To visualize the statements above in code, I started the real world conduit example, which is similar to the TodoMVC (https://github.com/mits-gossau/event-driven-web-components-todomvc-app) but more specific for a web application scenario: https://github.com/Weedshaker/event-driven-web-components-realworld-example-app

I would be very happy, if some of you guys would join the development process!? 🥰

Thanks for reading! 🙏

DEV Community: weedshaker

Build an Event Driven TodoMVC App with 8 lightweight VanillaJS Web Components

Demo

HTML Overview

Loading the Web Components

Event Driven

Overview of each Web Component

1. the "input.new-todo" gets NewTodo.js applied to it.

2. the "section.main" gets NoItemsHidden.js applied to it.

3. the "input.toggle-all" gets ToggleAll.js applied to it.

4. the "ul.todo-list" gets TodoList.js applied to it.

5. the "span.todo-count" gets TodoCount.js applied to it.

6. the "ul.filters" gets TodoFilters.js applied to it.

7. the "button.clear-completed" gets ClearCompleted.js applied to it.

8. the TodoItem.js gets loaded by TodoList.js when loadAllItems loads from localStorage or at the event 'new-todo'.

ShadowDOM and encapsulated CSS

Conclusion

Related Video Tutorials

Web Components and now what?

Related Video Tutorials

DOM and the event driven architecture - Introduction

Related Video Tutorials