XP Inc.
Published in

XP Inc.

Porque você deve (ou não) usar Web Components no seu Design System

Neste artigo você entenderá como a XP Inc. resolveu os desafios de criar um Design System com componentes compatíveis em diferentes bibliotecas, frameworks e arquiteturas Web.

O SOMA DS foi criado em Web Components com Stencil.js

Com grandes desafios vem grandes soluções.

A XP Inc. é uma companhia de tecnologia que opera no mercado financeiro expandindo para atender todos os serviços financeiros com o propósito de transformar e melhorar a vida das pessoas.

Atualmente a XP Inc. como toda empresa de tecnologia se encontra em um momento de grande escala na criação de produtos inovadores, e para conseguirmos chegar em uma solução sofisticada que pudesse entregar experiências únicas para os clientes e também padronizar a construção de aplicações web nesse grande e diverso ecossistema, criamos o Soma Design System (Soma DS).

O Soma DS entrega uma biblioteca de componentes visuais que são altamente reutilizáveis para que os times possam criar produtos com experiências incríveis, ele nasceu com um grande desafio de se adaptar a um ecossistema de desenvolvimento front-end diverso, onde cada time possui autonomia para criar suas aplicações web com a biblioteca, framework ou arquitetura que melhor atender as especificações técnicas do produto, temos produtos inteiramente criados a partir de React com Redux, Next.js, Angular, VueJS ou até mesmo sites desenvolvidos a partir de WordPress.

Depois de estudos e benchmarks decidimos seguir com o desafio de atender diferentes tecnologias e se adaptar a elas e a solução final foi desenvolver nossa biblioteca de componentes baseados em Web Components.

Web Components: a nova "Bala de Prata" ?

Web Components é uma terminologia usada para nomear um conjunto de tecnologias que possibilitam a criação de componentes customizados sem a necessidade de usar uma biblioteca ou framework base para isso, tudo pode ser feito com JavaScript puro, além de oferecer diversos outros benefícios que você conhecerá mais adiante.

Neste artigo não mergulharei nos detalhes, se você quiser entender de forma mais aprofundada sobre todos os conceitos e aplicações, você pode conferir o artigo: “Web Components: Criando componentes de forma agnóstica” escrito pelo Alexandre Servian que é um dos embaixadores do Soma DS.

A verdade é que novamente nos deparamos com uma solução incrível que resolve grandes desafios em relação a arquitetura front-end da companhia, porém mesmo assim ainda não existe a "Bala de Prata" que será eficaz para atender todos os cenários, então tivemos que "colocar na balança" todos os benefícios e problemáticas em relação a Web Components, e gostaria de compartilhar contigo os nossos aprendizados.

O SOMA DS é agnóstico a bibliotecas e frameworks JavaScript

Porque Web Components é a solução para o meu Design System ?

1. Eles possuem um bom suporte em browsers modernos

Os Web Components usam um conjunto de APIs padronizadas com suporte nativo em todos os navegadores modernos. Ainda existem limitações em alguns browsers (adivinha quais) por isso é necessário fazer um bom mapeamento da base de usuários das suas aplicações web para entender o comportamento de uso deles e quais browsers e versões são mais utilizadas por eles. Na XP Inc. vimos que 98% dos nossos clientes usavam nossas plataformas web em browsers modernos.

2. Eles ajudam a impulsionar a adoção do Design System

Um Design System só tem valor na medida em que é amplamente adotado pelos projetos e são mantidos e escalados pelos times. Ter um guia de estilo bem desenhado no Figma não garante que a experiência digital da empresa será consistente e acessível, por isso é necessário que os times usem componentes codados e prontos para entregar a experiência ideal para os usuários.

Com Web Components há alta compatibilidade, qualquer biblioteca ou framework baseado em JavaScript pode usá-lo, e esse foi um dos principais pontos que possibilitaram o sucesso do Soma DS na companhia, tivemos a oportunidade de entregar componentes independente se seriam utilizados em micro-frontends com React ou em uma aplicação web legada com Ember.js, isso deixou nosso Design System mais escalável!

O Soma DS hoje está presente em cerca de 200 repositórios web que compõem diversos projetos e iniciativas da XP, Clear, Rico entre outras empresas da XP Inc. Tudo isso foi possível por causa da escalabilidade de uma biblioteca agnóstica a framework.

3. Eles são à prova de futuro

Um dos benefícios do uso de Web Components é a segurança de que você não precisará "refazer" o seu Design System se a decisão de arquitetura front-end da empresa mudar.

Como Web Components é baseado em tecnologias nativas que qualquer biblioteca ou framework que interpreta DOM consegue entender, isso garante que tudo ficará bem se o Vale do Silício decidir criar mais um framework JavaScript que todo mundo vai querer usar.

4. Eles garantem padronização de estilo

O Shadow DOM é uma das APIs da suíte de Web Components que permite que os componentes tenham sua própria árvore DOM interna que não pode ser acidentalmente acessada ou modificada a partir do documento principal. Isso significa que tudo estará isolado e protegido contra modificações e estilos globais que a aplicação web possui, ou seja “tudo funciona” quando os componentes são implementados em diferentes ambientes e plataformas.

Com o Shadow DOM ganhamos também um ponto importante de um Design System que é a padronização e consistência no estilo dos componentes, no qual se a equipe de design determinou que um componente Button deve ser amarelo e o mesmo foi codado em Web Components dificilmente o desenvolvedor que usará o componente será capaz de mudar a cor deste Button para outra cor, ele que lute!

Isso garante que tudo estará exatamente da forma como foi desenhado pelos designers. Por outro lado essa abordagem também traz algumas problemáticas que devem ser resolvidas, abordarei elas mais adiante.

5. Temos incríveis toolchains para nos ajudar!

Talvez você já tenha visto alguns artigos sobre o assunto e se perguntou, como vou conseguir resolver a curva de aprendizado? Como desenvolvedores que estão acostumados a usar React com todos os seus inúmeros recursos para manipulação de DOM irá lidar com o fato de resolver isso tudo "na unha" com JavaScript puro ao criar Web Components?

É ai que entra os toolchains! Atualmente temos algumas soluções como LitElement, Svelte ou Stencil.js que nos ajudam com a missão de criar Web Components de forma simples e com recursos de sintaxe que fazem qualquer desenvolvedor front-end se sentir em casa. Basicamente você utiliza eles para criar seus componentes usando recursos para manipulação de DOM, estados, propriedades, eventos, lifecycle hooks e ao fazer o build tudo vira puramente uma biblioteca de Web Components.

Na XP Inc. optamos pelo uso do Stencil.js por alguns motivos:

  • Fornece Scaffoldings para criação de componentes, testes unitários, testes end-to-end, documentação de propriedades e eventos.
  • Nativamente usa JSX (o pessoal do React curtiu).
  • Nativamente usa TypeScript e Decorators (o pessoal do Angular curtiu).
  • Permite Lazy-Loading de componentes e assets.
  • Possui Polyfills para suporte a browsers antigos (o pessoal do IE curtiu).
  • Possui Output Targets no momento do build, no qual é gerado bibliotecas específicas com wrappers para React, Angular ou Vue para melhor compatibilidade com a biblioteca que vai utilizar o componente, assim seu componente terá a sintaxe e compatibilidade perfeita em diferentes tecnologias.
  • Existem grandes players que usam o Stencil.js como a Apple, Amazon, Microsoft além do famoso Ionic Framework.
  • O Stencil.js foi desenvolvido e é mantido pelo time do Ionic Framework, além de uma grande comunidade open-source.

Porque preciso pensar duas vezes antes de usar Web Components no meu Design System ?

1. O Suporte ainda é limitado em alguns navegadores

Como sempre existem browsers mais antigos que ainda não suportam a implementação das APIs que compõem os Web Components, como é o caso do Internet Explorer 11, algumas versões de Edge e também algumas versões de Firefox, você pode conferir todas as limitações no Can I Use.

Por isso é necessário que antes de tomar uma decisão seja feito um estudo de quais browsers e versões são utilizados por seus usuários. Mesmo assim ainda temos boas opções de Polyfills que resolvem essas limitações nos browsers antigos, o próprio Stencil.js já resolve esses problemas com os Polyfills que ele implementa nos Web Components gerados através do seu build, mas não resolverá todos os casos possíveis.

2. Existem problemas de compatibilidade em algumas bibliotecas e Frameworks específicos

É importante ressaltar que o suporte a Web Components ainda é um desafio quando implementado em bibliotecas e frameworks JavaScript como React, Angular ou Vue. Como eles manipulam o DOM e possuem muitas vezes formas diferentes de lidar com propriedades e eventos, possivelmente você pode encontrar algumas dificuldades ou side-effects.

No Custom Elements Everywhere você pode encontrar mais detalhes de como está o suporte dos Web Components pelos frameworks, mesmo assim o Stencil.js nos ajuda com essas limitações através dos Outputs Targets, que geram pacotes específicos em momento de build com componentes nativos de cada framework como wrappers para os custom elements, sendo assim grande parte (mas não todas) limitações são resolvidas.

3. Existem Problemas de compatibilidade com Server Side Rendering (SSR)

Muitas vezes você precisa utilizar os componentes em uma aplicação que é Server Side Rendering (SSR), infelizmente existem limitações em relação a renderização do ShadowDOM dos elementos quando a visualização é entregue para o cliente, atualmente isso está sendo largamente discutido pela comunidade.

Felizmente o Stencil.js conseguiu nos ajudar com essa problemática oferecendo um bundle pré-compilado para o hydrate no SSR.

Na XP Inc. conseguimos entregar nossa biblioteca para ser utilizada em aplicações com Next.js, ainda encontramos algumas limitações que conseguimos contornar com bibliotecas complementares, mas sem grandes impedimentos.

4. Pode existir limitações na customização de componentes

Como falado anteriormente, o Shadow DOM é um recurso que nos permite ter consistência na entrega de componentes padronizados por design, e que não poderão ser facilmente modificados pelos desenvolvedores que estão utilizando a biblioteca.

Entretanto isso pode se tornar um problema caso seja necessário que o desenvolvedor utilize um componente como base para criar um novo em sua aplicação web, ou quando realmente faz sentido uma pequena alteração no componente base para uma experiência diferente, aí teremos um problema!

Em alguns componentes você consegue facilitar a customização, deixando toda a estilização do componente no nível externo ao Shadow DOM, que é o host do custom element, no Stencil o host trabalha como o Fragment do React. Mesmo assim as vezes se torna inviável estilizar tudo em cima do host, você precisará ter elementos internos que serão encapsulados.

Na XP Inc. optamos por trabalhar com duas abordagens, primeiramente tentamos deixar alguns estilos que podem ser customizados no host do componente e trabalhamos na cultura da empresa em relação a evolução do Design System.

Trabalhar com cultura não é uma tarefa fácil (diria que é a mais complexa), nós desenvolvemos o Soma DS desde o início com a premissa de ser um produto inner-source da empresa, ou seja qualquer desenvolvedor poderá evoluir, corrigir ou criar um componente. Nós trabalhamos arduamente para deixar tudo o mais simples possível para que qualquer desenvolvedor, por mais júnior que seja, consiga mandar uma contribuição para o repositório do Soma DS. Assim quando existe alguma necessidade de modificação em um componente, o desenvolvedor junto com o designer pode trazer a sugestão para o time de Design System e por fim enviar sua contribuição no repositório via Pull Request.

5. É necessário uma boa documentação de uso dos componentes

A Documentação do seu Design System precisará ser muito bem estruturada para não causar confusão nos desenvolvedores que irão utilizar a biblioteca, pois cada biblioteca ou framework JavaScript pode ter suas especificidades em implementação do componente.

Na XP Inc. nós iniciamos nossa documentação técnica com Storybook, porém tínhamos muitas limitações de experiência ao compartilhar snippets de código personalizados para cada framework, então decidimos seguir com uma nova documentação feita do zero com Gatsby, onde integramos todo o conteúdo do ecossistema do Soma DS (Produto, Design, Web, iOS, Android, Xamarin) em um único lugar, neste vídeo falamos mais sobre essa mudança.

6. É necessário entender bem se Web Components realmente é necessário para a sua arquitetura

Um dos pontos importantes antes de iniciar a construção de um Design System é entender o cenário onde será utilizado, se a empresa já possui uma boa definição de stack front-end convencionada por arquitetura, e a empresa está madura nessa decisão, neste caso acredito que não faz sentido trazer uma abordagem de Web Components sendo que a empresa já trabalha com React ou Angular e não irá mudar isso no curto ou médio prazo, trazer uma nova abordagem irá mais atrapalhar a adoção do que dar produtividade para os times de desenvolvimento.

Na XP Inc. temos liberdade para escolher soluções e tecnologias de acordo com o nosso desafio de produto, desde que o mesmo esteja no nosso “Radar de Tecnologia” que é uma fonte de boas práticas e mapeamento de tecnologias recomendadas pela área de arquitetura de Software. Outro ponto que ponderamos é a estratégia de expansão da companhia que com certa frequência adquire outras empresas menores, essas empresas trazem produtos e times que estão muitas vezes maduros com uma linguagem ou stack diferente do resto da companhia e simplesmente “mudar tudo” de Angular para React somente para poderem utilizar o Soma DS não nos pareceu uma decisão inteligente.

7. É necessário um time com uma boa base de conhecimento técnico sobre fundamentos da web e frameworks JavaScript

Um time altamente capacitado e engajado é o que vai fortalecer as raízes do Design System para que possa escalar de forma sustentável. Trabalhar com Web Components não é uma tarefa fácil, existem vários pontos e descobertas que serão feitas no meio do caminho e que determinarão como a sua biblioteca vai escalar para atingir todas as pontas dos produtos da companhia.

É extremamente importante que o time técnico tenha bases sólidas de como funciona a arquitetura web em geral, como os browsers lidam com a renderização, emissão de eventos, estados, contextos entre outras coisas.

Além disso todos os dias na XP Inc. nos deparamos com problemas bem específicos de compatibilidade em aplicações construídas com bibliotecas e frameworks diferentes, ou ferramentas de testes, ou configurações em diferentes versões de Webpack, assim por diante. O time de Design System e toda a comunidade que irá contribuir com ela, deverá ter conhecimento base nestes diferentes frameworks e abordagens para conseguir resolver problemas comuns do dia-a-dia.

Conclusão

Entendemos que construir uma biblioteca de componentes agnóstica e escalável requer uma análise de diversos aspectos que irão impactar não somente como você constrói o Design System mas como outras pessoas irão usá-lo diariamente.

Na XP Inc. decidimos aceitar esses desafios e criar soluções internas que possibilitaram que tivéssemos os diversos benefícios de Web Components de uma forma sustentável.

Estamos colhendo bons frutos dessa decisão e escalando nossa biblioteca para todas as marcas da companhia, impactando positivamente centenas de desenvolvedores e entregando valor para milhões de clientes.

Quer saber mais?

Acesse nosso outro artigo no Medium da XP Inc.
Criando um Design System para múltiplas marcas

--

--

--

Aqui você vai encontrar os principais conteúdos de tecnologia, design, dados e produto da XP Inc.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Victor Caetano

Victor Caetano

Engineering Manager at XP Inc.

More from Medium

Interaction Design: 5 Components

Deploy a shared navigational experience across multiple content ecosystems within ibm.com/cloud

The design system value paradox, and how it was solved 30 years ago

Interactive Stories with CSF Play and User-Events