Design, develop and manage a catalog of Web Components Horacio Gonzalez - @LostInBrittany
April, 20-21-22, 2021
Slide 2
Who are we? Introducing myself and introducing OVH OVHcloud
Slide 3
Who are we? Introducing myself and introducing OVH OVHcloud
Slide 4
Horacio Gonzalez @LostInBrittany Spaniard lost in Brittany, developer, dreamer and all-around geek
Flutter
Flutter
Slide 5
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
Slide 6
The 3 minutes context What the heck are web component?
Slide 7
Web Components
Web standard W3C
Slide 8
Web Components
Available in all modern browsers: Firefox, Safari, Chrome
Slide 9
Web Components
Create your own HTML tags Encapsulating look and behavior
Slide 10
Web Components
Fully interoperable With other web components, with any framework
Slide 11
Web Components
CUSTOM ELEMENTS
SHADOW DOM
TEMPLATES
Slide 12
But in fact, it’s just an element…
● ● ● ●
Attributes Properties Methods Events
Slide 13
So, what are Design Systems? And why should I look at them?
Slide 14
A talk for devs by a dev
I am not a designer, neither I play one on TV…
Slide 15
The same or different?
Slide 16
Style Guides
A document listing the styles, patterns, practices, and principles of a brand design standards
Slide 17
Style Guides
Style guides define the application’s look and feel
Slide 18
Style Guide Example: Uber
https://brand.uber.com/
Slide 19
Style Guide Example: Medium
https://www.behance.net/gallery/7226653/Medium-Brand-Development
Slide 20
Style Guides alone are ambiguous
Interpretation needed to adapt the preconisation to the use case
Slide 21
Component Catalogs
A component catalog is a repository of components, with one or several implementations, code examples and technical documentation
Catalogs alone create inconsistency
Like using the same LEGO bricks to create very different objects
Slide 25
Design Systems
A Design System is like a common visual language for product teams
Slide 26
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
Slide 27
Design systems
Slide 28
Example: Carbon Design System
https://www.carbondesignsystem.com/
Slide 29
Example: Firefox’s Photon Design System
https://design.firefox.com/photon/
Slide 30
Example: Material Design
https://material.io/
Slide 31
The component catalog The poor relative of the Design System family
Slide 32
Let’s choose a simple example
Bootstrap based component catalogs
Slide 33
A long time ago
Components defined in HTML, CSS and some jQuery
Slide 34
Then it was AngularJS time…
And new reference implementations were needed
Slide 35
But you know the sad story…
All UI Bootstrap based catalogs woke up with an obsolete implementation
Slide 36
Worry no more, let’s do Angular!
ng-bootstrap to the rescue
Slide 37
But times had changed…
In 2017 Angular is only one more in the clique
Slide 38
TM
React is the new Big Thing
So let’s build React Bootstrap…
Slide 39
Wait, what about Vue?
We also need BootstrapVue
Slide 40
OK, I think you see my point…
Slide 41
Most Design System do a choice
Either they choose a canonical implementation or they ship and maintain several implementations
Slide 42
Both choices are problematic
Shipping only one implementation: Web dev ecosystem changes quickly and almost nobody keeps the same framework for years…
Slide 43
Both choices are problematic
Shipping several implementations: You need to maintain all the implementation… and you still miss some others
Slide 44
Incomplete catalogs are problematic
People will need to recode the components in their chosen framework… Coherence is not guaranteed!!!
Slide 45
Example: Carbon Design System
Slide 46
Web Components & Design Systems A match made in heaven
Slide 47
Compatibility is on Web Components side
Web Components everywhere, baby!
Slide 48
They are truly everywhere 🚀
🚀 Even in the spaaaaaaaace 🚀
Slide 49
Do you remember AngularJS?
And all the code put in the trash bin when Angular arrived…
Slide 50
The pain of switching frameworks?
Rewriting once again your code…
Slide 51
The impossibility of sharing UI code?
Between apps written with different frameworks
Slide 52
Web Components change that
In a clean and standard way
Slide 53
They are the interoperable alternative
Any framework… or no framework at all
Slide 54
You can have a single implementation
And it simply works everywhere
Slide 55
When you need interoperability
Nothing beats the standard
Slide 56
But how to do it? Designing, developing and managing a catalog of Web Components
Slide 57
Learning from the best
https://lion-web-components.netlify.app/
Slide 58
Learning from the best
https://github.com/CleverCloud/clever-components
Slide 59
What kind of components? From little atomic blocs to big smart components, and everything in between
Slide 60
A matter of size and complexity
What kind(s) of components you want to build
Slide 61
Build from the bottom and go up
Eat your own dog food
Slide 62
And how to choose the atoms?
Flexibility and configurability are key
Slide 63
And how to choose the atoms?
Encode often used patterns
Slide 64
And what about the molecules?
Capitalize on your atoms Keep the flexibility and configurability
Slide 65
Big smart business components
Encoding your business logic
Slide 66
Internal or external customers?
Who are your target users?
Slide 67
Internal customers need off-the-shelf components
A well defined and coherent look-and-feel
Slide 68
External customers need to be able to tweak
Theming and customizing components
Slide 69
How to organize the catalog Packages, imports and pragmatism
Slide 70
A single repository
Single source of truth for the catalog
Slide 71
Two schools of thought
A packet per component or a global one
Slide 72
Two schools of thought
Individual versioning vs global one
Slide 73
Lots of web components libraries LitElement
SkateJS
For different needs and sensibilities
Slide 74
Which ones to use?
All are good, but these are popular favorites
Slide 75
Driving-up adoption Making devs use your components
Slide 76
Think who are your target users
Users of any framework current or future…
Slide 77
They aren’t used to your library
And they shouldn’t need to be
Slide 78
Go the extra mile to drive up adoption
So they don’t need to do it
Slide 79
Make it easy to use
As easy as a HTML tag
Slide 80
Document every composant
How to use, inputs/outputs, examples…
Slide 81
Documentation isn’t enough
Storybook make adoption easy
Slide 82
Keeping a coherent writing style
Write down your guidelines
Slide 83
I18n shouldn’t be an afterthought
Prepare everything for internationalization