A presentation at NantesJS by Horacio Gonzalez
Design, develop and manage a catalog of Web Components Horacio Gonzalez 2021-01-21
Who are we? Introducing myself and introducing OVH OVHcloud
Horacio Gonzalez @LostInBrittany Spaniard lost in Brittany, developer, dreamer and all-around geek Flutter Flutter
OVHcloud: A global leader Web Cloud & Telcom 30 Data Centers in 12 locations 1 Million+ Servers produced since 1999 Private Cloud 34 Points of Presence on a 20 TBPS Bandwidth Network 1.5 Million Customers across 132 countries Public Cloud 2200 Employees worldwide 3.8 Million Websites hosting Storage 115K Private Cloud VMS running 1.5 Billion Euros Invested since 2016 300K Public Cloud instances running P.U.E. 1.09 Energy efficiency indicator 380K Physical Servers running in our data centers 20 Years in Business Disrupting since 1999 Network & Security
The 3 minutes context What the heck are web component?
Web Components Web standard W3C
Web Components Available in all modern browsers: Firefox, Safari, Chrome
Web Components Create your own HTML tags Encapsulating look and behavior
Web Components Fully interoperable With other web components, with any framework
Web Components
Custom Element
<body> … <script> window.customElements.define(‘my-element’, class extends HTMLElement {…}); </script> <my-element></my-element> </body>Shadow DOM <button>Hello, world!</button> <script> var host = document.querySelector(‘button’); const shadowRoot = host.attachShadow({mode:’open’}); shadowRoot.textContent = ‘こんにちは、影の世界!’; </script>
Template <template id=”mytemplate”> <img src=”” alt=”great image”> <div class=”comment”></div> </template> var t = document.querySelector(‘#mytemplate’); // Populate the src at runtime. t.content.querySelector(‘img’).src = ‘logo.png’; var clone = document.importNode(t.content, true); document.body.appendChild(clone);
But in fact, it’s just an element… ● ● ● ●
So, what are Design Systems? And why should I look at them?
A talk for devs by a dev I am not a designer, neither I play one on TV…
The same or different?
Style Guides A document listing the styles, patterns, practices, and principles of a brand design standards
Style Guides Style guides define the application’s look and feel
Style Guide Example: Uber https://brand.uber.com/
Style Guide Example: Medium https://www.behance.net/gallery/7226653/Medium-Brand-Development
Style Guides alone are ambiguous Interpretation needed to adapt the preconisation to the use case
Component Catalogs A component catalog is a repository of components, with one or several implementations, code examples and technical documentation
Component Catalog example: Bootstrap https://getbootstrap.com/
Component Catalog Example: ING’s Lion https://lion-web-components.netlify.app/
Catalogs alone create inconsistency Like using the same LEGO bricks to create very different objects
Design Systems A Design System is like a common visual language for product teams
Design systems A Design System is a set of design standards, documentations, and principles, alongside with the toolkit (UI patterns and code components) to achieve those standards
Design systems
Example: Carbon Design System https://www.carbondesignsystem.com/
Example: Firefox’s Photon Design System https://design.firefox.com/photon/
Example: Material Design https://material.io/
The component catalog The poor relative of the Design System family
Let’s choose a simple example Bootstrap based component catalogs
A long time ago Components defined in HTML, CSS and some jQuery
Then it was AngularJS time… And new reference implementations were needed
But you know the sad story… All UI Bootstrap based catalogs woke up with an obsolete implementation
Worry no more, let’s do Angular! ng-bootstrap to the rescue
But times had changed… In 2017 Angular is only one more in the clique
TM React is the new Big Thing So let’s build React Bootstrap…
Wait, what about Vue? We also need BootstrapVue
OK, I think you see my point…
Most Design System do a choice Either they choose a canonical implementation or they ship and maintain several implementations
Both choices are problematic Shipping only one implementation: Web dev ecosystem changes quickly and almost nobody keeps the same framework for years…
Both choices are problematic Shipping several implementations: You need to maintain all the implementation… and you still miss some others
Incomplete catalogs are problematic People will need to recode the components in their chosen framework… Coherence is not guaranteed!!!
Example: Carbon Design System
Web Components & Design Systems A match made in heaven
Compatibility is on Web Components side Web Components everywhere, baby!
Do you remember AngularJS? And all the code put in the trash bin when Angular arrived…
The pain of switching frameworks? Rewriting once again your code…
The impossibility of sharing UI code? Between apps written with different frameworks
Web Components change that In a clean and standard way
They are the interoperable alternative Any framework… or no framework at all
They are truly everywhere 🚀 🚀 Even in the spaaaaaaaace 🚀
You can have a single implementation And it simply works everywhere
When you need interoperability Nothing beats the standard
But how to do it? Designing, developing and managing a catalog of Web Components
Learning from the best https://lion-web-components.netlify.app/
Learning from the best https://github.com/CleverCloud/clever-components
What kind of components? From little atomic blocs to big smart components, and everything in between
A matter of size and complexity What kind(s) of components you want to build
Build from the bottom and go up Eat your own dog food
And how to choose the atoms? Flexibility and configurability are key
And how to choose the atoms? Encode often used patterns
And what about the molecules? Capitalize on your atoms Keep the flexibility and configurability
Big smart business components Encoding your business logic
Internal or external customers? Who are your target users?
Internal customers need off-the-shelf components A well defined and coherent look-and-feel
External customers need to be able to tweak Theming and customizing components
How to organize the catalog Packages, imports and pragmatism
A single repository Single source of truth for the catalog
Two schools of thought A packet per component or a global one
Two schools of thought Individual versioning vs global one
Lots of web components libraries LitElement SkateJS For different needs and sensibilities
Which ones to use? All are good, but these are popular favorites
Driving-up adoption Making devs use your components
Think who are your target users Users of any framework current or future…
They aren’t used to your library And they shouldn’t need to be
Go the extra mile to drive up adoption So they don’t need to do it
Make it easy to use As easy as a HTML tag
Document every composant How to use, inputs/outputs, examples…
Documentation isn’t enough Storybook make adoption easy
Keeping a coherent writing style Write down your guidelines
I18n shouldn’t be an afterthought Prepare everything for internationalization
That’s all, folks! Thank you all!
The world of web development is highly fragmented, with many incompatible frameworks: React, Angular, Vue …
It is so fragmented that some developers no longer describe themselves as web developers but as React developers or Angular developers. Code created for one of these frameworks will not work in others, forcing developers to rewrite their code every time they change frameworks.
In this context, Web Components represent one of the only multi-framework solutions for the Web. With Web Components, you can finally write your components once and for all, and use them everywhere: in React, in Angular, in Vue, but also in good old HTML pages without a framework.
That’s the theory, but how do you do this in practice? How do you build your component catalog, how do you structure it, how do you distribute these components?
In this talk we will give ideas, feedback and best practices for designing, developing and managing a catalog of web components, and how to use them in the different web frameworks.
