Feature externalizacao notificacoes

[Osdeni]

Para que possamos passar a utilizar a ferramenta em nosso projeto, ajustamos as notificações para serem usadas também de forma "fracionada", sem a necessidade de estar "anexa a barra de ferramentas superior", dando assim, maior liberdade visual para que nossa aplicação possa fazer uso da ferramenta já desenvolvida.

[gdfreitasdev]

Bom dia Osdeni!

Em análise em conjunto com a equipe, pontuamos alguns ajustes necessários para integrar essas mudanças ao nosso componente, seguindo o intuito de tornar o componente de notificações mais flexível para atender também layouts não padronizados por meio do Design System.

Sugerimos as seguintes alterações:

1. Utilizar a ferramenta Yarn para gestão das dependências, conforme a seção de Contribuindo > Ferramentas. Não commitar o package-lock.json.
2. Criar um componente <bth-painel-notificacoes> para contemplar o painel que foi fragmentado por meio de parâmetros. Utilizar este componente posteriormente no <bth-notificacoes>, desta forma as responsabilidades estarão melhor definidas. Lembrar de adicionar estes componentes ao índice de componentes públicos na seção "Ferramentas" do arquivo README.md
3. Pensar num formato onde não se faz necessário o uso do atributo height-painel-notificacoes="calc(100vh -150px), onde por exemplo o painel se adapta ao elemento externo ao qual foi inserido, mantendo simples e objetivo.
4. Implementar os devidos testes unitários das diferentes variações do(s) componente(s)
5. Caso seja necessário algum parâmetro/propriedade pública dos componentes, manter a preferência pelo portugues ao nomeá-los.
6. O evento conteudoSinalizado é um evento interno de um contrato entre componentes das "ferramentas" com o menu, utilizado na versão para dispositivos móveis. Portanto se faz necessário criar um novo evento para o componente de bth-painel-notificacoes para cumprir o propósito de informar a quantidade de notificações não lidas à quem tiver interesse, o mesmo serve caso outras informações sejam necessárias. Testar e documentar.
7. Descrever na documentação possíveis casos de uso desta abordagem, se possível exemplificando as variações, conforme exemplo das as documentações atuais.
8. Descrever na documentação as restrições visuais que o componente impõe, caso necessário, envolver alguém da equipe para elaboração das mesmas.
   • Exemplo: qual ícone utilizar, relação ícone/quantidade de itens não lidos, obrigatoriedade de ícone (painel pode ser usado sem ícone?)
   • Normativas de uso do ícone em relação a acessibilidade (badge vermelha em barra de menu vermelha, sem contraste, prejudica acessibilidade)
9. Implementar cenários na sandbox servida em http://localhost:3333/ para que possam ser manualmente testadas as diversas variações do componente
   • Por exemplo: dentro dropdown, em container menores/maiores, o conteúdo irá ter overflow? Pensar nos cenários possíveis.
   • Para a criação de um ambiente na sandbox, sugere-se a criação um arquivo html separado, à exemplo o ambiente de testes dos componentes comuns (comuns.html)