proto-argo-wc v0.1.0

proto-argo-wc

4 different implementations of the same ICO component:

• input-checkbox-toggle
• input-checkbox-toggle-alt
• input-checkbox-toggle-alt2
• ProtoArgoToggleFc

The original component used internal state and a change handler. The 1rst alternative removed internal state and made the component reactive to the application store. The 2nd alternative changed the class definitions from objects to strings using the tw utility. The last alternative made the component functional.

To run this locally, use the following:

yarn
yarn dev

reactive

• input-checkbox-toggle-alt

Changing the component to be reactive allows you to simplify the integration of the component and increases it's reuse. In this version, "isChecked" is a @Prop instead of an @State. The new change handler lets the wrapping component call an action to update the checked status in the application store. This makes the component purely reactive. It only reads the state and triggers a change call. It relies on the fact that the application store is the single source of truth. When the change handler is processed, the application store updates and then triggers the component to refresh with the new state.

tw utility

• input-checkbox-toggle-alt2

The tw utility is a simple class string utility which lets you compose complex class strings which may be dependent on properties. It's an alternative to the Object approach that the first 2 implementations use:

• input-checkbox-toggle
• input-checkbox-toggle-alt

It's probably just a personal preference, but i find the tw utility easier to understand and maintain. The object approach just feels like you are abusing the keys. In the end, both achieve the same results, but i prefer using the tw utility, YMMV.

functional

• ProtoArgoToggleFc

A functional component is just a DOM generator/utility, it takes props as input and has no state. Given the same props it will generate the same DOM every time. Since it's functional, it's not a real web component which has to be downloaded. Another side effect of being a functional component, there are no lifecycle methods, the component only responds to props. Effectively, a functional component is nothing more than a render method.

One advantage to functional components is the fact that since they only respond to props, you won't be tempted to introduce local state in your components.

Also, since functional components aren't real web components they don't have Shadow DOM, they just exist within a parent web component's DOM. This also means that they don't have local css, all of the css that they reference has to come from their parent. This works great if you are using Tailwind to define your styling. Tailwind will parse functional components for styling and include that in the parent's css.

Yet another advantage of functional components is the fact that they don't pollute the browser's component registry namespace. Since they are included in the web component's bundle, there's no risk of name conflicts for functional components.

dynamic tags

• proto-argo-wc

The top-level web component in this project demonstrates the use of a technique called dynamic tags. In a nutshell, Stencil allows you to reference a component by it's string name and then dynamically instantiate it.

IMPORTANT: this technique only works for class based web components in Stencil. You can't use this for functional components...

Here's a simple example in a fictitious render method:

const TAG = input ? 'input-checkbox' : 'ro-checkbox';

return <TAG></Tag>

This would instantiate either a input-checkbox or ro-checkbox web component when that render method runs, depending on the value of the input boolean. What this means is that it's now possible to dynamically instantiate UI elements based on for example, component names stored in a JSON object.

One potential use case for this might be forms, where you'd define the form in a JSON object and one property might be the component name (string). When you render the JSON, you'd use that component name and dynamically instantiate the appropriate component needed for the form element. Of course, this is probably easier said than done, but in theory this technique could be used to dynamically build forms from data.