Framework de interface (UI) agnostico ao framework JS

[akfzambrana]

Boa tarde pessoal.

Estava discutindo com o @woliveiras no slack do ABC sobre a possibilidade de criar um "framework" de UI agnóstico ao framework JS (angular, react, etc).

Cenário atual

É uma realidade que depois que perdemos a separação do layout e comportamento algumas mudanças são muito mais dificeis do que outras (não é objetivo discutir se isto é bom ou não, essa é uma guerra perdida já 😉) pois da forma em que os frameworks UI são criados atualmente, eles estão intrinsecamente linkados a um framework JS e são construidos encima deste (utilizando os recursos do mesmo para facilitar o trabalho e aumentar a produtividade).

Então quando você (ou sua equipe) quer/precisa mudar a tecnologia/framework, precisa reescrever absolutamente tudo, mesmo que o design e UX não tenham mudado. Ou as vezes, caso você utilize o design de um framework (BS por exemplo), você é obrigado a mudar o seu design apenas porque não existe BS para a sua nova tecnologia/framework, mesmo que o "comportamento de um modal, abas, acordion, etc" sejam exatamente os mesmos (e a base de todos frameworks JS seja o JavaScript).

O ideal

O mais top dos mundos seria ter um framework de interface (tipo angular material, jquery ui, etc) que fosse 100% agnóstico à tecnologia utilizada pra consumir os dados de APIs, construir os templates, etc. fazendo com que todo o "comportamento" padrão do componente fosse programado em JS puro, pois todo modal precisa abrir, fechar, confirmar, **tem largura e altura configuraveis, posicionamento (e algumas outras coisas que não to lembrando agora) que são 100% independentes de como e quando isso irá acontecer que já ficaria a cargo do "controle" da tecnologia que consome as APIs e controla seus templates.

Vantagens do "ideal"

Tendo um framework UI assim, seria possível mudar a "tecnologia" da sua aplicação sem ter que reescrever absolutamente toda a interface e design, o que permitiria uma curva de aceitação (por parte dos donos, gerentes, etc) da "refatoração" muito menor, já que seria investido um tempo e esforço menores. A reciproca também seria verdadeira, ja que você (ou a sua equipe) poderia decidir mudar a UI sem precisar mudar o restante da aplicação o que facilitaria a evolução do seu design sem precisar mudar a tecnologia.

A duvida

• Sera que criar algo assim seria possível?
• Existe algo assim tão **independente"?

Frameworks utilizando apenas CSS

Apesar de existir algumas opções, elas são bem limitadas e as vezes exigem um markup não tão semântico.

PS: Desculpem qualquer erro de digitação/conhecimento e agradeço as suas opiniões.

Update: Um amigo me passou este artigo que fala sobre algo do tipo http://www.benfarrell.com/2015/10/26/es6-web-components-part-1-a-man-without-a-framework/

[paulinhapenedo]

Acho que isso é o que os Web Components querem resolver. Um componente que exista e dependa apenas de si mesmo para funcionar (apresentação e comportamento básico), independente de frameworks/libs externas.

Acredito que é algo que todos os fronts mais voltados pra UI desejam hahaha não precisar reescrever comportamento de dropdown, modal, collapse e etc de acordo com o framework/lib do momento/projeto. Eu adoraria isso!

[fbadaro]

Olá @akfzambrana acho que a resposta da @paulinhapenedo segue a mesma linha do que a gente tava falando no slack ontem, seguindo o que estava pesquisando e para a galera que quiser dar uma olhada, tem este post bem bacana A Man Without a Framework e tem esta spec do Custom Elements do MDN.

[fdaciuk]

Tenho algumas reflexões com relação ao assunto:

Markup

Do ponto de vista de markup, seria impossível fazer algo que funcione com todo e qualquer framework / lib existente e ainda assim seja fácil de manter. Teria que ser feito uma duplicação gigante de código nessa lib para funcionar de forma agnóstica, pois cada lib / framework que se propõe a fazer isso, procura fazer a geração do markup da forma mais performática possível, e cada um tem a sua forma de fazer.

Web Components tem sua pegada própria para resolver isso (com Shadow DOM, Custom Elements, HTML imports, etc), como o React tem o dele, como o Angular tem o dele, como o Ember tem o dele, etc.

Existe inclusive algumas libs que tentam ser o mais Vanilla JS possível, como o hyperx, mas ainda assim ele usa técnicas para a geração do markup ser a mais performática possível, com Virtual DOM.

Então, sobre o markup, não acredito que seja possível encontrar uma solução agnóstica, a menos que todas as libs suportem qualquer tipo de marcação de forma agnóstica (o que eu acho praticamente impossível). Óbvio, posso estar deixando de considerar algum ponto importante que faça toda a diferença, mas hoje eu não consigo ver uma solução pra isso.

Mas tem um outro ponto que já reduziria boa parte do trabalho: a parte lógica.

Lógica

Componentes como modal, slider, paginação, accordion, etc., têm uma regra padrão por trás, e algumas regras específicas podem ser adicionadas.

Criando uma lib de comportamentos e não de marcação, podemos chegar bem próximos do desejado nesse caso: óbvio que, para cada lib, teria o trabalho de implementar conforme as suas próprias regras de markup, mas uma lib JS de paginação funcionaria para qualquer framework / lib que se propõe a gerenciar o markup. Tenho um exemplo disso aqui.

O exemplo foi feito com um componente do React, mas a lógica da paginação foi separada do componente. Eu posso usar essa lógica com qualquer framework / lib, que a regra da paginação vai funcionar igual.

Se seguir por esse caminho, separando a lógica do markup, eu acredito que dá pra economizar bastante trabalho quando precisar trocar de framework =)

[darlanmendonca]

eu tenho trabalhado nessa mesma idéia há algum tempo, cerca de 6 meses

entre muitos commits, e refatorações, o que tenho testado é o seguinte approach

• web components, usando customElements, eu consigo criar uma tag, e associar a ela uma classe, com construtor e métodos, de instancia ou staticos, etc.

cada component é feito com js puro e é um módulo a ser instalado via npm (tentei bower, mas fiquei insatisfeito c uns bagui)

uma vez q este módulo é o component, e possui tda a lógica doq ele deve fazer, e do visual q deve ter, ele é o meu "core"

daí p kda framework, lanço um "porte" para o meu módulo, exemplo, pra angular, eu crio uma diretiva, pra react/vue um component, em q este usa como "core" o módulo em js puro

isso permite centralizar tda a lógica/estilo/comportamento no core (js e css), e "portar" para um o framework, e utilizando os plus de kda framework.

essa é a idéia, oq tenho sentido q é treta, é q, fazer algo agnóstico, exige um conhecimento mto profundo sobre td, pois vc ira tocar em tdas as camadas, exemplo, clean-code, peso do módulo, facilidad d manutenção, extensibilidad, performance.

exemplos, de camadas

Design

mais um exemplo, eu stou fazendo aki um módulo q é um select, como em termos de design eu qro algo já pronto pra usar, q combine com n layouts, e q seja fácil d por sua própria identidad, eu xamei os components de minimalist-components, dawe o nome do bagui é mn-select, e por awe vai, mn-tipoDeComponent.

aki o link do mn-select

ele é só um select, q em termos de design, é minimalista, ponto.

n tem mtas cores, pq qro algo ameno, q combine c td, e q seja fácil d "sobrescrever" a identidade, sem mtos overrides de css, etc, mas isto explico melhor mais abaixo, q tem mais q apenas isso

UX

ele é diferente no mobile, no mobile eu pnsei antes em ser uma layer, mas akabei axando mto bacana ser um component d "meia-layer" (n sei o nome crto do bangs), q tem no android e ios

Acessibilidade

ele funciona com tab, setas, esc, etc (desktop claro). e ainda irei colocar filtro (conforme vc digita, dmarca os itens, exemplo, digitei "st", dawe o item "stark" e outros q contenham staram em destaque, mais ainda to ponderando dtalhes desse rolê, por isso ainda n ta feito

ok, estas foram algumas coisas q definiram o meu component em design e ux, agora pros code

Clean-code

td mundo imagina um select do jeito q é nativamente, mudar isso a n ser q seja uma idéia melhor, n será uma boa idéia, tipo reiventar a roda, manja
por isso, sempre tento expor algo q td mundo ja conhece, ou se n conhece, num unico olhar ja grave, por ser simples, ficou assim o code pra usar

<mn-select placeholder="House">
  <option value='stark'>Stark</option>
  <option value='lannister'>Lannister</option>
</mn-select>

e há duas formas de setar um valor inicial, add o attributo selected a um option, eg.

<option value='stark' selected>Stark</option>

ou usando o attr value na tag mn-select

<mn-select placeholder="House" value="lannister">

documentacao

ahh, tem as docs, td isso no readme, e é dificil pnsar em algo q seja fácil/curto, organizar msmo, mas vale a pna pra quem vai usar, e pra eu tenho q screver na doc td, rs (facilidade de documentar)

por hora tenho colocado num simples readme, e n qro q um component seja "complexo" pra tomar mto tmpo diariamente d quem stiver usando, qro algo produtivo

compatibilidade

ainda n stou lidando c IExplorer, só chrome, safari, firefox, tem coisas mto bestas q ferram o rolê, é xato, mas se cuidar disso corretamente, n da trampo infinito n, rs. exemplo, tag option n é aceita nem renderizada se n for num select d vrdad no safari, oq me força a "regerar" o markup, eu troco no dom as tags (options viram divs), coisas assim.

peso

esse component, tem um "design" c uma linha embaixo, e q qdo ta invalido é vermelho, etc.
outros components, como o mn-input tbm, e tem o mn-password, e o mn-email, e por awe vai, elementos q tem um q de input.

dawe pra reduzir o peso d kda kra, eu tenho q separar devidamente em módulos, ou seja, o mn-select tem como dependencias

{
  dependencies: {
    'mn-backdrop': '^0.02',
     'mn-card': '^0.03',
     'mn-input': '^0.04',
     'open-color': '^1.4.2',
  },
}

mn-backdrop é o fundo cinza q aparece, tanto no select, como num mn-dialog, ou num mn-sidenav, por ser um só, menos bytes, redundantes, e facilita a quem usar sobrescrever o stilo, sei la no seu site o fundo do backdrop é rosa, basta um body:before {background: pink}, e voi-la.

mn-card é o card, q sabe definir paddings pra um card, paddings somente no titulo, etc. dawe reaproveito

mn-input é quem define o visual d inputs, e tem validacao, dawe o mn-select usa esse visual, e extende esses comportamentos, e implementa uns novos, ja q é um select

open-color é a paleta d cores q to usando em tds os components, rs

enfim, saber separar uma coisa num módulo da trabalho, é dificil "enxergar" plenament td, se skeço d algo, ou n enxergo, la na frente vai gerar mtos commits, pra ir refatorando, mas vale mto a pna

tests

por ser um módulo a parte, ajuda a fazer tests, por ser um repo/projeto q é tbm um "escopo" menor. é mto insustentavel num projeto/produto testar mil coisas ao msmo tmpo, por ser modularizado, ajuda a criar um mundo organizado, e eu n fico louco no processo ou mantendo estes inumeros tests

css

o css ja sta pronto, inclua no projeto e use, mas vc provalvemente ira querer redefinir a identidad, adicionando cores, fonts, spacamentos, detalhes, enfim. sao simples de se sobrescrever, e se vc notar q sao mtas sobrescritas, vale a pna n incluir o meu css, e sim, copiar e modificar e fazer o seu. Irei documentar isso direitinho, mas ja tenho feitos ests tests em um protótipo c identidade "material-design".

porte para frameworks

estou testando ja fazer uma diretiva pra angular, e services, q apenas invocam as coisas do core. pra react/vue ainda n screvi nda, mas plo ando aprendido sobre vuejs e react, é semelhante ao q tenho feito no angular. envolve eu "expor" corretamente os métodos na minha classe, pois o Core, tem uma classe es6, ou seja, é mais qustao d analisar as props e métodos q aquela classe deve ter

conclusao

citei estas acima como exemplo pratico do q tenho sentido, a "complexidade" q é fazer algo como isto, e estas sao a ponta do iceberg que eu enxerguei até o momento. c ctz irei me deparar c outras

masssss, acredito q sim, q seja possível sim fazer algo agnóstico a framework

[akfzambrana]

Po @darlanmendonca curti muito a ideia e vou estudar bastante seus codigos pq achei super interessante o jeito que esta lidando com os componentes. Obrigada!

[darlanmendonca]

opa @akfzambrana seria nice!!!
neste minimalist ou em outro q por ventura venha a surgir, precisamos mto d um framework agnóstico :D

qto ao minimalist, em ordem de complexiddade, lhe sugiro olhar estes primeiro

• mn-backdrop
• mn-sidenav

pois tem poucas dependências e comportamentos :D