Definições
Avaliar tecnicamente os aspectos relativos ao frontend, como bibliotecas, documentação, typagem e usar ou não usar UI frameworks
Fonte: https://www.npmtrends.com/angular-vs-react-vs-vue
Fonte: https://insights.stackoverflow.com/survey/2018/#technology
Um UI framework é uma biblioteca de componentes para interface de usuário (ex.: botões e caixas de texto) que podem ser utilizados em conjunto para construir a camada visual da aplicação.
Avaliando a implementação dos itens que iremos necessitar, obtivemos a seguinte tabela:
UI Framework | Sim | Não |
---|---|---|
Material-UI | 24 | 3 |
Ant Design | 23 | 4 |
Fabric | 21 | 6 |
Groomet | 21 | 6 |
Semantic-UI | 20 | 7 |
Blueprint | 19 | 8 |
Carbon | 13 | 14 |
Material-UI
Ant Design
Semantic-UI
Antes da avaliação dos frameworks, foi realizado a construção dos componentes presentes no protótipo.
Como teremos uma identidade visual própria, há a necessidade de documentação desses componentes que serão criados, e hoje, vemos duas principais libs em cena, o Storybook e o Docz.
O Storybook é uma lib que tem o foco em ser um ambiente de desenvolvimento para UI components e testes, podendo ser configurada para dar log nos event handlers como onClick e onChange.
Já o Docz é uma lib criado por um brasileiro que vem com a proposta de realizar documentações com ZERO configuração. Ela é uma lib que utiliza MDX para exibir os componentes em meio a um markdown.
Para essa análise utilizei o Storybook na versão 3.4.10 e o Docz na 0.10.2.
Configurando os dois projetos, consegui as seguintes telas:
Storybook
Dentre as duas libs, optei pelo Docz que disponibiliza uma documentação completa e interativa de fácil configuração, basta ter um arquivo .mdx com a configuração que você deseja ela já será adicionada ao menu lateral.
Você também pode interagir com os componentes listados.
Obs: Há a possibilidade de termos as duas libs configuradas no projeto, mas como é possível fazer a mesma coisa com as duas libs, não vejo sentido em fazer duas vezes a mesma coisa.
Com a tipagem estática, temos o benefício de pegar erros em tempo de compilação ao invés de runtime, melhorando a leitura e auxiliando na refatoração do código, além de trazer sugestões mais precisas na IDE.
Algumas situações em que é recomendado a utilização de tipagem estática é quando:
O Flow é um typechecker criado pelo Facebook para JavaScript, podendo realizar inferência de tipos através de análise de código, assim você não precisa tipar tudo (mas quanto mais, melhor) e tem a promessa de fácil integração com feedback em tempo real.
Já o TypeScript é um superset do JavaScript que compila pra JavaScript puro e foi criado pela Microsoft. Se você utiliza o VsCode, ele já vem configurado para dar suporte a TypeScript.
Após ler os artigos abaixo e trocar uma ideia com o Sibelius e o Marcelo...
...cheguei as seguintes conclusões:
Prós
Contras
Prós
Contras
TypeScript
Por possuir uma comunidade maior e mais antiga, possui muitas definições de tipos feitas e com a versão TS3, ele se tornou tão bom quanto o Flow para tipagem de React.
/src - Agrupador da estrutura do produto
/apollo - Queries, mutations e definições do client GraphQL
/assets - Imagens, template HTML e arquivos scss
/components - Nossos componentes React (a carinha bonita)
/containers - Faz a ligação entre componentes e o Apollo
App.tsx - Arquivo de entrada
tsconfig.json - Configurações do TypeScript
tslint.json - Configurações de Lint do TypeScript
package.json - Definições do projeto
webpack.config.js - Configurações do webpack