Migração dos componentes do RP-1 para o apollo-11

[renatosrib]

Esses componentes podem ser migrados para centralizar todos nossos componentes no apollo-11. Entretanto, como o RP-1 foi pensado para ser usado somente em projetos da Synchro, ele possui alguns componentes que podem necessitar de modificação. Seguem abaixo os pontos encontrados até o momento::

• synchro-area: terá que ser renomado para alguma outra coisa, tal como, apollo-area.
• menu-app: temos que pensar em uma nova forma de distribuir os icones para aplicação, para que eles não fiquem dentro do apollo-11. Talvez colocar em algum servidor por exemplo, e passar o link associado no objeto. Ex:

  [
    { appName: 'ACCOUNTS', href: '', icon: 'http://algumEndereço/accounts.svg' },
    { appName: 'AE', href: '', icon: 'http://algumEndereço/ae.svg' },
    ...
  ];

[marcio]

Acredito que podemos pensar nas áreas que temos no nosso header, de cara vejo as seguintes:

<UserBox /> que é apenas o circulo do usuário. <AppsMenu /> menu de aplicações. <Notifications /> sino de notificações.

Esses caras poderiam ser usados diretamente, um a um ou ainda podemos pensar em algo como o Synchro Área para encapsular esses componentes.

<HeaderArea 
  userBox={{
    showNickName: false,
    otherConfig: true
  }}
  appsMenu={[
    {app: 'A', link: '/asdas/asdasd', icon: 'a.svg'}, 
    {app: 'B', link: '/bsdas/xvasd', icon: 'b.svg'}
  ]} 
/>

Nesse caso, renderizaria o user box, não renderizaria as notificações e criaria o menu de apps com a lista recebida.

<HeaderArea 
  userBox={{
    showNickName: false,
    otherConfig: true
  }}
  notifications={{
    provider: storeToListen,
    otherConfig: ''
  }} 
  appsMenu={[
    {app: 'A', link: '/asdas/asdasd', icon: 'a.svg'}, 
    {app: 'B', link: '/bsdas/xvasd', icon: 'b.svg'}
  ]} 
/>

Caso onde renderizaria todos os componentes.

Acho válido a gente discutir a API de cada componente. e o HeaderArea seria apenas um wrapper para os mesmos.

[renatosrib]

Concordo em irmos nessa direção. Mas como passaríamos o conteúdo PopOver do <UserBox />? Por Prop?

[marcio]

Exato, temos que primeiro fechar o que vai ter no user box, e se o user box precisar ser "dinâmico" podemos continuar passando por props, só que ai a gente passa o componente como prop. Ex:

<HeaderArea 
  userBox={ <UserBox prop1="" prop2=""><div>children</div></UserBox>}
  appsMenu={[
    {app: 'A', link: '/asdas/asdasd', icon: 'a.svg'}, 
    {app: 'B', link: '/bsdas/xvasd', icon: 'b.svg'}
  ]} 
/>

Nesse caso o HeaderArea perde um pouco o poder, visto que vai ser preciso definir o UserBox, agora se as configs do UserBox forem estáticas podemos passar só um objeto com os valores necessário. Como no meu comentário anterior.

[mvgnunes]

Atualmente, no REINF foi adicionado uma funcionalidade de alterar a senha do usuário dentro desse componente. Futuramente acredito que isso não fique no escopo das aplicações, mas temos que pensar em cenários assim.

[studiojms]

Acredito que adicionar esses componentes no apollo seriam bons para ajudar a padronização de nossos produtos. Seria interessante criar algo que facilite a utilização e permita customização. Sobre a parte do menu-app, em vez de ter os ícones e nomes de aplicações no componente, será que não podemos prover apenas o container (a casca) do menu no apollo e para renderizar os itens, pensar em alguma outra forma de popular o conteúdo?

Imagino que essa solução de menu com itens sempre demandará que todos sempre atualizem o componente para ter o menu com tudo o que for necessário, sendo que os itens do menu são dinâmicos, vão evoluir com o tempo... talvez possamos chamar algum serviço que possa prover os itens de menu e suas características (ícone, nome etc).