Apr 19, 2018
Quid: a tool for composing Web Components
Web Components has been gaining a lot of momentum in the latest’s months. Projects like Polymer has been envisioning and pushing the approach for years. At the same time, Technology standardization lead by the W3C recommendations, and adoption on all the modern browsers have made Web Components technologies progressing quickly toward implementation.
Basically, Web Components are based on the following technologies:
- HTML Templates
- Custom Elements
- HTML Imports
- Shadow DOM
- and Script TYPE=”module”
You can track browser’s support here or here.
Moreover, once standardized and natively supported in browsers, web development frameworks have started to rethink and realign their approaches to benefit from the new opportunities that web components are putting into the table. Some examples include:
- Polymer provides a simple and elegant approach to create web components today.
- Ionic Team is building Stencil to allow web components interop between frameworks.
- The Angular Team is building Angular Elements to make it even easier to produce reusable web components with minimal framework footprint from an angular component. Video,
- SkateJS,
- VueJS,
- Svelte, and more.
See a great repo with samples for comparison at shprink/web-components-todo.
- Catalogs for Web Components are also starting to appear and it is not a far away we will see a COTS (the component of the shell approach) to create web apps. Open source or paid components, we will found a myriad of web components ready to be used.
- Google itself is testing Web Components in the YouTube User Interface.
- Banks like BBVA in Spain are building their own set of components to achieve a homogeneous in all channels and unique look & feel UX in its apps.
With this panorama, I am pretty sure we will see more and more web component collections created with different frameworks.
A Missing feature in Web Components for easier composition
Type System
No matter if you are a big fan of dynamic languages. The reality is that components are types to be consumed by others. They expose a set of well-known properties with known types, events and actions/methods. When discovering a catalog of components, a standard for type description is missing to help people and tools to validate the usage of the component (for example, to provide code completion).
If type information is present, the following aspect can be enforced:
- Autodiscovery and checking for usage of only valid properties
- Checking types
- Checking method signatures and valid invocation parameters
- Code completion can be provided by tools
Moreover, some components can act as containers for other ones, working in cooperation. Example: tab controls use to contain tabs, a carousel expects some images or panes to be placed as child components.
Type information should inform also what types of components are valid as children. If they must adhere to a protocol for interoperation, a “duck typing” interface could do the trick.
As a simile, think about a JS lib, compared with a TS lib providing type info (a JS lib with a *.d.ts definition could do the trick also).
A standard way to expose this information is still to be defined. In the meantime, in absence of type info, when importing a new component, the type signature must be made explicit to know about valid compositions.
Quid
In this context, we see a need for tools helping on Web Component composition and consumption. That’s why we have created a new tool called: Quid.
Try Quid directly or watch this short video to see how it works.
With Quid we want to explore how easy a tool for Web Component composition should it be:
- To extend: allowing to import 3rd party components
- able to use them to create pages or new components
- reducing the unnecessary syntax increasing the signal/noise ratio
- able to prototype it in real time to achieve a WYSIWYG experience
- ready to produce the markup and code of the composition ready to glue into your website or app
Extensible list of components
In Quid you will be able to import third-party components you want to work with (not yet ready, work in progress). Lacking type information, you will need to define the contract as commented before. But then, it will be ready for consumption.
Easy to specify
Working with HTML, XML or JSON uses to involve adding a lot of ‘< / >’ for the first two and ‘{ “ = }” for the latter. YAML is another incarnation of JSON removing the extra noise.
In Quid, we wanted to explicitly remove what we call “the noise” and put the focus on the important aspects: component names, events and properties.
That is why, in Quid, you will find an indentation based DSL aggressively distilled to the minimum possible to keep you focused and making it as easy as possible to read.
WYSIWYG
What You See Is What You Get: We think immediate feedback is key to keep the user in the loop, that why Quid renders your design on the fly.
Different targets
Instead of producing a unique output (HTML + JS + Web Component glue), we envision you would like to inject your creation to work in cooperation with different host frameworks like Polymer, Angular, React, VueJS, Stencil, etc. and choose your base language for scripting like Javascript, TypeScript, or Flow.
That’s doable with Quid. Which flavor do you prefer? Which ones would we support? If you have opinions on that, we want to know.
Your feedback needed
Feel free to try Quid (in beta) and send us feedback. We would love to hear you about if covers your case of use.
We think we are still in the early days of Web Components adoption, but chances are high they will be here to stay, so let’s build great tools to make it easy to work with!
