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