Design, develop and manage a catalog of Web Components

A presentation at FrontSide Conf in October 2020 in Paris, France by Horacio Gonzalez

Slide 1

Slide 1

Design, develop and manage a catalog of Web Components Horacio Gonzalez 2020-10-15

Slide 2

Slide 2

Who are we? Introducing myself and introducing OVH OVHcloud

Slide 3

Slide 3

Horacio Gonzalez @LostInBrittany Spaniard lost in Brittany, developer, dreamer and all-around geek Flutter Flutter

Slide 4

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

Slide 5

The 3 minutes context What the heck are web component?

Slide 6

Slide 6

Web Components Web standard W3C

Slide 7

Slide 7

Web Components Available in all modern browsers: Firefox, Safari, Chrome

Slide 8

Slide 8

Web Components Create your own HTML tags Encapsulating look and behavior

Slide 9

Slide 9

Web Components Fully interoperable With other web components, with any framework

Slide 10

Slide 10

Web Components

Slide 11

Slide 11

Custom Element

<body> … <script> window.customElements.define(‘my-element’, class extends HTMLElement {…}); </script> <my-element></my-element> </body>

Slide 12

Slide 12

Shadow DOM <button>Hello, world!</button> <script> var host = document.querySelector(‘button’); const shadowRoot = host.attachShadow({mode:’open’}); shadowRoot.textContent = ‘こんにちは、影の世界!’; </script>

Slide 13

Slide 13

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);

Slide 14

Slide 14

But in fact, it’s just an element… ● ● ● ●

Slide 15

Slide 15

So, what are Design Systems? And why should I look at them?

Slide 16

Slide 16

A talk for devs by a dev I am not a designer, neither I play one on TV…

Slide 17

Slide 17

The same or different?

Slide 18

Slide 18

Style Guides A document listing the styles, patterns, practices, and principles of a brand design standards

Slide 19

Slide 19

Style Guides Style guides define the application’s look and feel

Slide 20

Slide 20

Style Guide Example: Uber https://brand.uber.com/

Slide 21

Slide 21

Style Guide Example: Medium https://www.behance.net/gallery/7226653/Medium-Brand-Development

Slide 22

Slide 22

Style Guides alone are ambiguous Interpretation needed to adapt the preconisation to the use case

Slide 23

Slide 23

Component Catalogs A component catalog is a repository of components, with one or several implementations, code examples and technical documentation

Slide 24

Slide 24

Component Catalog example: Bootstrap https://getbootstrap.com/

Slide 25

Slide 25

Component Catalog Example: ING’s Lion https://lion-web-components.netlify.app/

Slide 26

Slide 26

Catalogs alone create inconsistency Like using the same LEGO bricks to create very different objects

Slide 27

Slide 27

Design Systems A Design System is like a common visual language for product teams

Slide 28

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

Slide 29

Design systems

Slide 30

Slide 30

Example: Carbon Design System https://www.carbondesignsystem.com/

Slide 31

Slide 31

Example: Firefox’s Photon Design System https://design.firefox.com/photon/

Slide 32

Slide 32

Example: Material Design https://material.io/

Slide 33

Slide 33

The component catalog The poor relative of the Design System family

Slide 34

Slide 34

Let’s choose a simple example Bootstrap based component catalogs

Slide 35

Slide 35

A long time ago Components defined in HTML, CSS and some jQuery

Slide 36

Slide 36

Then it was AngularJS time… And new reference implementations were needed

Slide 37

Slide 37

But you know the sad story… All UI Bootstrap based catalogs woke up with an obsolete implementation

Slide 38

Slide 38

Worry no more, let’s do Angular! ng-bootstrap to the rescue

Slide 39

Slide 39

But times had changed… In 2017 Angular is only one more in the clique

Slide 40

Slide 40

TM React is the new Big Thing So let’s build React Bootstrap…

Slide 41

Slide 41

Wait, what about Vue? We also need BootstrapVue

Slide 42

Slide 42

OK, I think you see my point…

Slide 43

Slide 43

Most Design System do a choice Either they choose a canonical implementation or they ship and maintain several implementations

Slide 44

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

Slide 45

Both choices are problematic Shipping several implementations: You need to maintain all the implementation… and you still miss some others

Slide 46

Slide 46

Incomplete catalogs are problematic People will need to recode the components in their chosen framework… Coherence is not guaranteed!!!

Slide 47

Slide 47

Example: Carbon Design System

Slide 48

Slide 48

Web Components & Design Systems A match made in heaven

Slide 49

Slide 49

Compatibility is on Web Components side Web Components everywhere, baby!

Slide 50

Slide 50

Do you remember AngularJS? And all the code put in the trash bin when Angular arrived…

Slide 51

Slide 51

The pain of switching frameworks? Rewriting once again your code…

Slide 52

Slide 52

The impossibility of sharing UI code? Between apps written with different frameworks

Slide 53

Slide 53

Web Components change that In a clean and standard way

Slide 54

Slide 54

They are the interoperable alternative Any framework… or no framework at all

Slide 55

Slide 55

They are truly everywhere 🚀 🚀 Even in the spaaaaaaaace 🚀

Slide 56

Slide 56

You can have a single implementation And it simply works everywhere

Slide 57

Slide 57

When you need interoperability Nothing beats the standard

Slide 58

Slide 58

But how to do it? Designing, developing and managing a catalog of Web Components

Slide 59

Slide 59

Learning from the best https://lion-web-components.netlify.app/

Slide 60

Slide 60

Learning from the best https://github.com/CleverCloud/clever-components

Slide 61

Slide 61

What kind of components? From little atomic blocs to big smart components, and everything in between

Slide 62

Slide 62

A matter of size and complexity What kind(s) of components you want to build

Slide 63

Slide 63

Build from the bottom and go up Eat your own dog food

Slide 64

Slide 64

And how to choose the atoms? Flexibility and configurability are key

Slide 65

Slide 65

And how to choose the atoms? Encode often used patterns

Slide 66

Slide 66

And what about the molecules? Capitalize on your atoms Keep the flexibility and configurability

Slide 67

Slide 67

Big smart business components Encoding your business logic

Slide 68

Slide 68

Internal or external customers? Who are your target users?

Slide 69

Slide 69

Internal customers need off-the-shelf components A well defined and coherent look-and-feel

Slide 70

Slide 70

External customers need to be able to tweak Theming and customizing components

Slide 71

Slide 71

How to organize the catalog Packages, imports and pragmatism

Slide 72

Slide 72

A single repository Single source of truth for the catalog

Slide 73

Slide 73

Two schools of thought A packet per component or a global one

Slide 74

Slide 74

Two schools of thought Individual versioning vs global one

Slide 75

Slide 75

Lots of web components libraries LitElement SkateJS For different needs and sensibilities

Slide 76

Slide 76

Which ones to use? All are good, but these are popular favorites

Slide 77

Slide 77

Driving-up adoption Making devs use your components

Slide 78

Slide 78

Think who are your target users Users of any framework current or future…

Slide 79

Slide 79

They aren’t used to your library And they shouldn’t need to be

Slide 80

Slide 80

Go the extra mile to drive up adoption So they don’t need to do it

Slide 81

Slide 81

Make it easy to use As easy as a HTML tag

Slide 82

Slide 82

Document every composant How to use, inputs/outputs, examples…

Slide 83

Slide 83

Documentation isn’t enough Storybook make adoption easy

Slide 84

Slide 84

Keeping a coherent writing style Write down your guidelines

Slide 85

Slide 85

I18n shouldn’t be an afterthought Prepare everything for internationalization

Slide 86

Slide 86

That’s all, folks! Thank you all!