Trabalhar com a equipe de backend para padronizar e melhorar o payload no que diz respeito ao beagle-web

As ações de navegação pushViewAction, pushStackAction e ResetNavigationAction foram alteradas:

interface RemoteView {
  url: string,
  fallback?: BeagleUIElement,
  shouldPrefetch?: boolean,
}

interface LocalView {
  screen: BeagleUIElement,
}

type Route = LocalView | RemoteView

interface PushStackAction {
  _actionType_: 'pushStack',
  route: Route,
}

interface PushViewAction {
  _actionType_: 'pushView',
  route: Route,
}

interface ResetNavigationAction {
  _actionType_: 'resetNavigation',
  route: Route,
}

Para resolver esta issue basta alterar os contratos.

• issue para implementar o shouldPrefetch: #68
• issue para implementar o screen e o fallback: #67

Beagle Web version:

Steps To Reproduce

1. Utilizar o beagleContext.replace em um elemento que é a raíz da árvore
2. A árvore não é atualizada. Caso o elemento não seja a raíz, funciona corretamente

Link to code example:

The current behavior

The expected behavior

Algumas classes estão vindo do BFF maiusulas e com _
Ajustar para tratar esses cenários para o padrão do web minuscula separando por -

What would you like to be added:
Uma nova ação foi criada: "beagle:submitForm". Ela deve submeter o formulário pai. Além disso, é importante que botões que disparam essa ação tenham type "submit" (para fins de acessibilidade).

Why is this needed:
Foi decidido em reunião com todas as frentes.

O Beagle funciona muito bem e de maneira muito simples para views com complexidade baixa. Mas, basta adicionar interação entre os componentes que a implementação se complica. A interação entre componentes no Beagle exige que o desenvolvedor entenda padrões de como contexto e observable. Além disso, em grande parte das vezes, essa interação exige que o dev acople sua aplicação ao Beagle em alguns componentes chaves.

Exemplos de interação entre componentes que o Beagle não consegue resolver por si só, requerindo habilidade do desenvolvedor e código adicional na aplicação:

• Parágrafo reativo: dois componentes: um text-area e um parágrafo. Tudo que é digitado no text-area deve ser impresso no parágrafo.
• Controle de modal: dois componentes: um botão e uma modal. Ao clicar no botão, a modal deve ser aberta. Ao clicar no botão de "close" da modal, a modal deve ser fechada.
• Submissão de formulários: Ao submeter um formulário, deve-se enviar os valores de todos os campos para uma determinada URL (ajax/XHR). Em caso de sucesso, a view do beagle deve renderizar a URL correspondente ao próximo passo. Em caso de erro, deve-se exibir uma rápida mensagem dizendo que ocorreu um erro.
• Auto-complete em campos de endereço: suponha um formulário de endereço com os campos: cep, rua, número, bairro, estado e cidade. Ao preencher o cep, uma requisição deve ser feita à api dos correios passando o cep digitado. Como resultado, essa api retorna os valores para rua, bairro, cidade e estado. Esses campos devem ser atualizados no formulário de acordo com a resposta trazida pela api dos correios.
• Validação de formulários: os campos de um formulários podem ter validações como "required", "less-than-or-equal (lte)", "cpf", "email", etc. Se um campo tem validação, a validação deve ser checada antes de submeter o formulário. Se ocorre erro de validação, o erro deve ser mostrado junto ao input e o formulário deve ser impedido de ser submetido.

Configurar CI/CD para o projeto do beagle-web.

• Armazenar as key para o CD no secrets do GitHub
• Gerar release notes automaticamente?
• CI/CD automático de novas versões
• Geração de release notes
• Adicionar template para PR

Deve-se replicar todas as funcionalidades de Analytics do iOS e do Android nas libs para web.

Não confundir com o Analytics 2.0

As features do playground para o lançamento da V1 do Beagle devem ser finalizadas.

Essas features estão no seguinte board:
https://github.com/ZupIT/beagle-creator/projects/3

Criar documentação para o beagle-web no gitbook

Adicionar eslint ao projeto

A propriedade _beagleType_ está sendo renomeada para _beagleComponent_. Devemos implementar as alterações.

Como _beagleComponent_ já indica que se trata de um componente, o prefixo :component dos componentes padrões devem ser removidos. Por exemplo: beagle:component:button de torna beagle:button.

What would you like to be added:
Devido a problemas com a linguagem Kotlin, foi necessário mudar a sintaxe das expressões de ${variavel} para @{variavel}. Consertar em todos os lugares do beagle-web que esperam a sintaxe antiga.

Why is this needed:
A sintaxe anterior causava problemas na linguagem Kotlin

Os seguintes testes devem passar em todas as frentes do Beagle:

[
    {
        "base": "http://base.url",
        "path": "/relativePath",
        "result": "http://base.url/relativePath"
    },
    {
        "base": "http://base.url",
        "path": "absolutePath",
        "result": "absolutePath"
    },
    {
        "base": "http://base.url",
        "path": "//weirdPath",
        "result": "http://base.url//weirdPath"
    },
    {
        "base": "http://base.url",
        "path": "/",
        "result": "http://base.url/"
    },
    {
        "base": "http://base.url",
        "path": "",
        "result": null
    },
    {
        "base": "http://base.ending.with.slash/",
        "path": "/relativePath",
        "result": "http://base.ending.with.slash/relativePath"
    },
    {
        "base": "http://base.ending.with.slash/",
        "path": "absolutePath",
        "result": "absolutePath"
    },
    {
        "base": "http://base.ending.with.slash/",
        "path": "//weirdPath",
        "result": "http://base.ending.with.slash//weirdPath"
    },
    {
        "base": "http://base.ending.with.slash/",
        "path": "/",
        "result": "http://base.ending.with.slash/"
    },
    {
        "base": "http://base.ending.with.slash/",
        "path": "",
        "result": null
    },
    {
        "base": "http://base.url/withPath",
        "path": "/relativePath",
        "result": "http://base.url/withPath/relativePath"
    },
    {
        "base": "http://base.url/withPath",
        "path": "absolutePath",
        "result": "absolutePath"
    },
    {
        "base": "http://base.url/withPath",
        "path": "//weirdPath",
        "result": "http://base.url/withPath//weirdPath"
    },
    {
        "base": "http://base.url/withPath",
        "path": "/",
        "result": "http://base.url/withPath/"
    },
    {
        "base": "http://base.url/withPath",
        "path": "",
        "result": null
    },
    {
        "base": null,
        "path": "/relativePath",
        "result": "/relativePath"
    },
    {
        "base": null,
        "path": "absolutePath",
        "result": "absolutePath"
    },
    {
        "base": null,
        "path": "//weirdPath",
        "result": "//weirdPath"
    },
    {
        "base": null,
        "path": "/",
        "result": null
    },
    {
        "base": null,
        "path": "",
        "result": null
    }
]

Acredito que todos os testes acima passariam, com exceção dos paths que começam com "//".

Deve-se alterar os testes para o urlBuilder e alterar o comportamento deste caso algum dos testes não passe.

Criar possibilidade do desenvolvedor optar em utilizar o Browser History em sua navegação pelo Beagle.

What would you like to be added:
Criar um novo parâmetro na configuração de uma view que determina o tipo de navegação da mesma. Esse poderá ser BROWSER_HISTORY ou BEAGLE_NAVIGATOR (default).

Why is this needed:
Atualmente o Beagle Navigator não interfere no history do browser, apenas altera o fluxo de paths dentro de uma view. Essa issue aberta explica este fluxo.
A ideia é disponibilizar a opção em que o Beagle Navigator também altera o history do browser. Nessa opção, ao executar uma ação de navegação, o beagle deve alterar a url adicionando uma query string com o path desejado.

Obs.: Essa é a primeira solução pensada não definitiva.

No Beagle context é possível fazer um:

• append: adiciona um filho ao componente em questão. Elemento será adicionado ao final da lista.
• prepend: adiciona um filho ao componente em questão. Elemento será adicionado ao início da lista.
• replace: seguindo a mesma linha de raciocínio, acredito que deva substituir os filhos do componente em questão pelo novo elemento. Mas, na verdade, ele substitui o elemento inteiro na árvore e não sua lista de filhos.

Esse comportamento está ok? Estou achando confuso, o que vcs acham?

Toda ação do beagle deve ter um prefixo. Esse prefixo é "beagle:" caso seja uma ação default e "custom:" caso seja uma ação customizada.

O prefixo "custom:" deve ser adicionado automaticamente à configuração do Beagle, o dev não deve ser obrigado a digitar isso. Deve-se tomar cuidado apenas para não se adicionar "custom:" se o dev estiver tentando substituir uma ação padrão (prefixada por "beagle:").

Widgets:

• Button
• Text
• Container
• Image
• Loading
• Error

ServerDrivenComponent:

• ListView
• Screen
• ScrollView
• Lazy
• Page
• TabBar
• Touchable

What would you like to be added:

• Criar um novo repositório beagle-web-components
• Separar componentes do Beagle Angular
• Separar componentes do Beagle React
• Unificar estilos e interfaces.
• Deixar de usar StyledComponentes.
• Remover dependência CSSType no Angular
• Importar as libs de componente nas respectivas libs.
• Exibir warning de que os componentes padrões não farão parte da lib principal a partir das próximas versões.

Why is this needed:

O intuito da nossa lib é de renderização e portanto os componentes deveriam estar desacoplados da lib.

Atualmente usamos o Lodash no beagle-web. No beagle-angular, para diminuir o tamanho do pacote, não usamos o Lodash. Mas, como o beagle-angular depende do beagle-web, nosso esforço de não usar o Lodash no beagle-angular não está valendo de nada.

Podemos seguir de duas maneiras:

1. Retiramos o Lodash do beagle-web , refatorando tudo o que usa o Lodash.
2. Liberamos o uso do Lodash, inclusive no beagle-angular.

Votem aí pessoal. 1 ou 2? Justifiquem suas respostas 😆

Hoje temos as operações de append, prepend e replace na árvore de componentes. append e prepend garantidamente representam um conteúdo novo, portanto recebem novos ids.

No caso do replace, se eu estiver atualizando um conteúdo que já existia, só deveriam receber ids novos componentes que não existiam na árvore até o momento. Hoje, todo elemento da árvore recebe um id novo na operação de replace. Deveria existir uma opção no replace que permitiria manter os ids anteriores (keepIds, por exemplo).

Outra opção seria diferenciar replace de update. replace simplesmente trocaria o conteúdo, sem se preocupar com os ids, como faz hoje. update, manteria os ids de estruturas que já existiam anteriormente na árvore.

Terminando a v1.0, precisamos voltar e analisar tudo o que fizemos até o momento. O que não está legal, o que podemos refatorar? O que não está claro e podemos melhorar?

Diante dessas perguntas, criei um documento com algumas ideias sobre problemas que observamos durante a v1.0 e que podemos melhorar para a próxima versão. Espero sugestões de todos, seja comentando nessa issue ou submetendo PR's para o documento que escrevi.

Criar componentes customs para o playground no Angular. Usar os componentes no React como referência.

• Modal
• TextArea
• TextInput

Middlewares assíncronos podem ser úteis em alguns casos. Veja o exemplo de um projeto no Itaú:

• Existe um projeto que faz uma server driven UI através de um XML, eles querem transformar esse XML em um json e usar o beagle.
• O XML traz apenas a estrutura. Os valores são informados em forma de template, por exemplo: <Label Name="lblEstadoCivilValor" Content="{Binding EstadoCivilValor}" ToolTip="{Binding EstadoCivilValor}" Padding="2"/>. Nesse código, {Binding EstadoCivilValor} deve ser substituído pelo valor em um json que vem de outro serviço.
• A solução mais interessante para esse problema seria criar um middleware que faz a requisição que traz o json com os valores e substitui na árvore todo valor no formato {Binding nome_da_variavel}.

Requisições são assíncronas e portanto não suportadas pela api de middlewares. Deve-se adicionar suporte à middlewares assíncronos no Beagle.

Para que possamos implementar alguma interface funcional na web, precisamos de alguns componentes ou propriedades que não existem no mobile. Precisamos dessas coisas implementadas por enquanto pelo menos para o bom funcionamento do Playground. Depois podemos discutir a necessidade de colocá-los como padrões no Beagle ou removê-los, deixando-os como custom.

Button

• precisamos de type?: 'button' | 'submit' | 'reset'
• precisamos de primary?: boolean
• precisamos de disabled?: boolean

Form

Precisamos de um componente de Form:

interface Props {
  isLoading?: boolean,
  onSubmit?: () => void,
  onReset?: () => void,
}

Modal

Precisamos de um componente de Modal:

interface Modal {
  isOpen: boolean,
  onClose: () => void,
}

TextInput

Precisamos de um componente de TextInput:

interface TextInput {
  value: string,
  label?: string,
  placeholder?: string,
  name?: string,
  type?: string,
  disabled?: boolean,
  readonly?: boolean,
  onChange?: (value: string) => void,
  onFocus?: (value: string) => void,
  onBlur?: (value: string) => void,
}

Comentar nesta issue para discutir novos componentes essenciais. A intenção principal é criar um playground que consiga criar interfaces funcionais. No futuro, podemos discutir a inclusão desses no mobile.

Atualização 04/05

• middlewares/beagleId
• utils/string - https://github.com/ZupIT/beagle-web-ce/pull/50
• index

popToView, popView, e popStack deveriam recuperar o estado anterior das views. Hoje, apenas criamos uma instancia nova usando o mesmo json que deu origem à view.

Por exemplo, suponha que a view "form" seja um formulário com vários campos. O usuário preenche os campos "nome" e "cpf" e logo depois navega de "form" para outra página chamada "statement". Se em "statement" ele receber uma navegação popView, ele deveria retornar para a view "form" e os campos "nome" e "cpf" deveriam estar preenchidos, pois a view já existia e estava em memória. O estado deve ser mantido, assim como no Android e iOS. Na web, nós criamos uma instância nova da view, portanto, o form viria vazio.

Objetivo desta issue:

• Decidir se devemos corrigir esse problema.
• Implementar correção.

Criar artigos que mostram passo-a-passo como construir as POCs usando Beagle.

A propriedade _actionType_ está sendo renomeada para _beagleAction_. Devemos implementar as alterações.

Atualmente os estilos precisam ser tratados nos middwares.
Oferecer suporte a um processo de tratamento de styles padrões (margin, padding, flex, cores)

Para que o Beagle funcione, apenas um domínio deve ser utilizado para as views remotas. Não é possível, por exemplo, trazer algumas views de https://www.lorem.com e outras views de https://www.ipsum.com.

O Beagle WEB, permite as seguintes situações:

• O tipo LoadParams aceita o parâmetro baseUrl, o que está errado, pois a única baseUrl que deve ser utilizada é aquela passada na configuração. Corrigindo esse problema, os fixme relacionados a esse problema na lib do Angular e do React devem ser removidos.
• path em LoadParams será SEMPRE relativo, pois isso é usado apenas para carregar views. Portanto, podemos colocar o prefixo /, caso o usuário esqueça. Evitando o problema onde path="movies" é diferente de path="/movies"

Atenção: o tipo de URLBuilder.build pode ser mantido, pois esse utilitário pode ser usado para coisas além do fetch de views.

What would you like to be added:
Conforme conversado com o B1 em 09/06, a propriedade direction foi removida no bff e mobiles e os valores start e end tanto da margin quanto do padding também foram removidos. Logo podemos removê-los das nossas tratativas no middleware de style.

Why is this needed:
Para consistência com os ajustes mobile e bff

O Beagle é responsável por realizar todas as requisições HTTP's feitas durante o processo de construção da aplicação. No entanto, pode haver a necessidade do usuário de utilizar um cliente customizado para realizar estas requisições. Seja motivado, pelo uso de interceptors, headers, ou outras possibilidades de configuração de um cliente. Portanto, será adicionado esta possibilidade de configurar o cliente e passá-lo ao Beagle para que as chamadas sejam feitas através do mesmo.

Dependência

Esta issue considera que as mudanças de contrato especificadas em #66 já foram implementadas.

shouldPrefetch

Se route.shouldPrefetch é true, a view indicada por route.url deve ser pré-carregada.

No PR #5 , a lógica de comparar as props (inputs) para ver se elas estão disponíveis no componente local e ignorá-las caso não estejam é uma particularidade que precisamos no Angular. Não acho que esteja ligado a renderização do XML em si. Além disso, "getInputNames" não sugere que isso vai gerar o comportamento que está gerando. Pra não acoplar essa lógica ao core, sugeriria adotar uma das seguintes abordagens:

• a opção formatAttributeNames pode voltar null ao invés de uma string. Se formatAttributeNames retorna null, igoramos essa propriedade/input/prop

• Implementar a opção shouldAddAttribute que recebe o attributeName e o attributeValue. Se retornar true, colocamos o atributo, caso contrário, não colocamos.

Dessa forma, passaríamos essa lógica de comparar os inputs dos componentes para o beagle-angular, que é onde realmente precisamos dela.

Dependência

Esta issue considera que as mudanças de contrato especificadas em #66 já foram implementadas.

Screen

O JSON do Beagle permite que que uma view seja definida dentro de outra. Isso é feito através do componente especial beagle:component:screen.

beagle:component:screen define uma nova árvore de UI que nada mais que é que outra view (json). Além disso, beagle:component:screen só pode ser encontrado dentro de ações de navegação.

Uma navegação, ao invés de especificar uma url, pode especificar uma screen. Dessa forma, não é necessário ir no backend e buscar a próxima view, basta usar o json que veio como valor da propriedade screen. Veja um exemplo:

{
  "_beagleType_": "beagle:component:button",
  "id": "navigationButton",
  "text": "Clique para navegar",
  "onPress": {
    "_actionType_": "pushView",
    "route": {
      "screen": {
         "_beagleType_": "beagle:component:container",
         "id": "anotherView",
         "children": [
           {
             "_beagleType_": "beagle:component:text",
             "text":  "Another view"
           }
         ]
       }
      }
    }
  }
}

O JSON acima renderiza apenas uma view com um botão. O container de id "anotherView" não será renderizado, pois na verdade ele define uma outra view!

Ao clicar no botão de id "navigationButton", o usuário irá navegar para view cuja raiz é o container de id "anotherView". Ou seja, o que vem dentro do campo "route.screen" de uma ação de navegação é sempre a definição de uma outra view.

Fallback

Fallback é um problema similar ao Screen, a diferença é que a view declarada dentro de route.fallback só é renderizada caso não seja possível carregar route.url.

Remover obrigatoriedade dos componentes de loading e error no atributo components da config já que a partir do momento que temos os componentes padrões eles podem ser utilizados como default sem precisar forçar o usuário a criar componentes próprios.

What would you like to be added:
Remover obrigatoriedade dos componentes de loading e error na config

Why is this needed:
Permitir que que o beagle automaticamente identifique que é para usar os componentes de erro e loading padrões (quando o usuário não definir um, hoje isso não é possível porque os componentes são obrigatórios).

O tratamento de custom components está diferente do restante do beagle:

• O beagle espera que todo custom component tenha o prefixo 'custom:'.
• Nós não exigimos isso no web. Na verdade, também não exigem nas outras frentes. Isso acontece por trás dos panos. Todo componente cadastrado pelo desenvolvedor recebe o prefixo "custom:".
• Não podemos adicionar "custom:" a todo componente cadastrado no web, pois deve também ser possível substituir os componentes padrões. No iOS e no Android, eles impedem que os componentes padrões sejam substituídos.
• Como precisamos permitir a substituição de componentes padrões (no web), devemos verificar o nome do componente, se ele se inicia com "beagle:", não adicionamos o prefixo "custom:", caso contrário, adicionamos.

Beagle Web version: 0.2.0

Steps To Reproduce

1. Run the demo for default components and change the mock payload for tab-view in order to have a child node inside tab view items. The payload will look like this:

{
   "_beagleComponent_": "beagle:container",
   "child": {
      "_beagleComponent_": "beagle:tabview",
      "tabItems": [
         {
            "title": "Button",
            "child": {
               "_beagleComponent_": "beagle:container",
               "children": [ ... ],
               ...others
            }
         },
         {
            "title": "Container",
            "child": {
               "_beagleComponent_": "beagle:container",
               "child": {
                  "_beagleComponent_": "beagle:text",
                  ...others
               },
               ...others
            }
         }
      ]
   }
}

2. Trying this demo, you'll see that the second tab won't be rendered.

The current behavior

Because of the order of the middleware and because that beagleConvertChildToChildren won't reach the tabView items that contain child nodes, these nodes won't be converted and Beagle will not render them.

The expected behavior

The child node must be converted to a children node.

beagle:button deve ser equivalente a BEAglE:bUTTon

beagle:pushView deve ser equivalente a beagle:pushview

Finalizar as tasks exclusivas do Angular para a V1.

Link para o board:
https://github.com/ZupIT/beagle-web-angular/projects/2

Tornar este repositório público

Epic: ZupIT/beagle#745
Proposal: https://github.com/ZupIT/beagle-web-core/tree/specification/analytics2

O Analytics 2.0 tem os seguintes objetivos:

• Criar uma interface genérica e poderosa que pode ser implementada em todas as plataformas e integradas com qualquer serviço de analytics.
• Além de expor os métodos dessa API para o cadastro manual de entradas (records) no analytics, devemos criar uma metodologia automatizada de criação de analytics, sem que seja necessário codificação por parte do desenvolvedor.
• Devemos criar uma implementação dessa API para o BeagleAnalytics. Um backend que deve ser desenvolvido como ferramenta de analytics padrão.
• Com uma ferramenta de analytics automatizada implementada, poderemos começar a criar estratégias para a utilização inteligente desses dados.

Atenção: não confundir com o Analytics 1.0. O Analytics 2.0 está em fase de pesquisa e ainda precisa ser muito bem discutido.

Deve-se construir uma lib para React Native com base no beagle-react.

What would you like to be added:
Criar middlewares padrões para converter de child para children

Why is this needed:
Alguns componentes padrões trazem child ao inves de children. Precisamos ajustar para correta renderização dos componentes.
São eles:

• touchable
• screen

Finalizar as tasks exclusivas do React para a V1.

Link para o board:
https://github.com/ZupIT/beagle-web-react/projects/2

Junto ao backend e mobile, finalizar a definição do componente de imagem: ZupIT/beagle#105

Implementar as definições da issue acima e corrigir o seguinte problema:
Para imagens locais, apenas copia-se o valor de "url" para a propriedade "src" do elemento "image". Dessa forma, a imagem será relativa ao caminho da view atual. Não é essa a intenção. O caminho que vem em "url" é relativo à raiz do projeto.

Widgets:

• Button
• Text
• Container
• Image
• Loading
• Error

ServerDrivenComponent:

• ListView
• Screen
• ScrollView
• Lazy
• Page
• TabBar
• Touchable