Executando verificação de segurança...
4

Não entendi muito bem o objetivo do seu framework, mas não me parece que ele resolve nenhum problema real no desenvolvimento web moderno.

Quanto as features que você citou, não me parece uma boa ideia usar chaves para isso, de um ponto de vista de UX, você está quebrando a heurística da familiaridade, e também não está dando nenhum benefício extra com isso, visto que deve ser mais rápido digitar uma tag do que isso ai num editor moderno.

Se você acha muito ruim digitar uma tag, além de não querer ter um processo de build, saber tomar vantagem de técnicas como a composição talvez torne a sua vida mais fácil.

Você pode simplesmente ter funções com bons nomes e que seguem a mesma interface, assim você termina com um código parecido com o do Flutter e qualquer outro framework de desenvolvimento de UI não baseado em XML (tipo o SwiftUI). Ex:

section(p("Hello world!"))

De qualquer forma, se você realmente gostar da ideia de um template customizado, eu recomendaria remover de vez ou os <> ou as {}, os dois no mesmo lugar estão praticamente fazendo o mesmo papel.

Outra ideia seria escrever a sua linguagem de template por cima do pug/jade se for só para facilitar na hora de digitar.

Sobre o namespace, uma feature de registrar o componente com um nome associado a ele igual é no Vue já seria mais do que suficiente, no JSX como você está lidando com JS puro só que com uma sintaxe diferente isso nunca foi um problema devido a você conseguir criar um namespace na hora de importar, e no pior dos casos, uma boa prática em várias das comunidades é simplesmente uma convenção de nome, então isso já estaria resolvido de qualquer forma também.

Sobre tipagem dos atributos, seria melhor expor uma API que usa o TS para inferir os tipos dos parâmetros através de um builder ou algo como o que a composition API do Vue faz.

Isso que você está fazendo ia acabar sendo uma versão bem pior do prop-types que ficou bem obsoleto já atualmente.

Carregando publicação patrocinada...
0