torus
Minor rendering bug fixes
torus-dom )O Torus é uma estrutura de interface do usuário de visualização de modelo orientada a eventos para a Web, focada em ser minúsculo, eficiente e livre de dependências .
Você pode encontrar o? Documentação completa para o Torus aqui, nas páginas do Github .
A Torus também possui uma versão anotada e fácil de ler de toda a base de código (bastante concisa), também nas páginas do GitHub. Confira se você quiser saber mais sobre como as estruturas são projetadas e como funciona o DOM virtual e o modelo!
Aqui está a aparência do Torus em ação! Este é um aplicativo de contador totalmente funcional, não é necessária etapas de compilação ou agrupamento.
Solte esta tag de script em seu html
< script src =" https://unpkg.com/torus-dom/dist/index.min.js " > </ script >... e carregue este script.
// every view extends Component or StyledComponent
class App extends Torus . StyledComponent {
init ( ) {
// initialize our local state
this . count = 0 ;
}
styles ( ) {
// we can define dynamically and efficiently injected
// styles for our component with styles(), like this.
// These styles are also automatically scoped to the
// component, and we can use the full, nested SCSS syntax.
return css `
font-family: system-ui, sans-serif;
h1 {
text-align: center;
}
button {
padding: 4px 8px;
&:hover {
opacity: .8;
}
}
` ;
}
compose ( ) {
// We define the structure of our component in compose(),
// using a JSX- and lit-html-like syntax as a template string.
return jdom `<main>
<h1>Hi! You clicked ${ this . count } times.</h1>
<button onclick=" ${ ( ) => {
this . count ++ ;
this . render ( ) ;
} } ">Count up!</button>
</main>` ;
}
}
// mount the app to the page
document . body . appendChild ( new App ( ) . node ) ; O Torus não possui dependências de produção, não requer etapa de construção para aproveitar todos os seus recursos e pesa menos de 5 kb de Gzipped, incluindo o motor de modelos, renderizador, componente e sistema de eventos e o invólucro CSS-in-JS. Isso simplifica a adoção e o envio, para qualquer coisa, desde a renderização de um único componente na página até a criação de aplicativos em grande escala.
O Torus não foi projetado para ser a biblioteca Virtual DOM mais rápida (existem ótimas alternativas como inferno ), mas o desempenho e a capacidade de resposta estão entre os principais objetivos do projeto. Embora permaneça minúsculo, o Torus tenta ser o mais rápido e receptivo possível, especialmente na renderização. Combinado com o tamanho pequeno do pacote, isso torna o Torus ótimo para criar aplicativos da Web para qualquer lugar, em qualquer dispositivo.
A arquitetura do Torus encapsula toda a lógica de renderização e atualização dentro do próprio componente, por isso é seguro pegar Component#node e tratá -lo como um ponteiro simples para o elemento raiz do componente. Você pode movê -lo pela página, retirá -lo e sair do documento, incorporá -lo em componentes reagir ou vue ou mesmo componentes da web e usá -lo em qualquer lugar em que um elemento DOM tradicional possa ser usado. Isso permite que você inclua componentes e aplicativos do Torus em uma variedade de arquiteturas de front -end.
Combinado com o pequeno tamanho do toro, isso torna razoável enviar o toro com apenas um ou alguns componentes para um projeto maior que inclui elementos de outras estruturas, se você não quiser ou não pode enviar um aplicativo de toro inteiro.
O Torus não se preocupa com a internacionalização, mas, como desenvolvedores, podemos usar as APIs disponíveis para possibilitar a internacionalização dentro de nossos componentes do Torus. O Torus expõe grande parte do processo de renderização e o DOM virtual a você, o desenvolvedor e, de maneira importante, nos permite criar um preprocessor que possa receber a jddom e modificá -lo antes que ele chegue ao renderizador, para que possamos fazer modificações no DOM que o renderizador vê com nosso próprio código. Isso torna o Torus altamente extensível e ideal para i18n. De fato, a API de pré -processador do componente é o que torna possível os componentes do Torus Styled() . ( Styled() adiciona um novo nome de classe à jddom antes que o componente seja renderizado.)
Por exemplo, podemos fazer um I18nComponent , que pode atuar como uma classe de componente base para um projeto internacionalizado, como este.
class I18nComponent extends Component {
// The default preprocess method just returns the jdom as-is. We can override it
// to modify the JDOM given by component's `#compose()` method before it reaches the
// virtual DOM renderer.
preprocess ( jdom , _data ) {
// Here, we might recursively traverse the JDOM tree of children
// and call some custom `translate()` function on each string child
// and any displayed props like `placeholder` and `title`.
// As a trivial example, if we only cared about text nodes on the page,
// we could write...
const translate = jdom => {
if ( typeof jdom === 'string' ) {
// translate text nodes
return yourImplementationOfTranslateString ( jdom ) ;
} else if ( Array . isArray ( jdom . children ) ) {
// it's an object-form JDOM, so recursively translate children
jdom . children = jdom . children . map ( yourImplementationOfTranslateString ) ;
return jdom ;
}
return jdom ;
}
// In production, we'd also want to translate some user-visible properties,
// so we may also detect and translate attrs like `title` and `placeholder`.
return translate ( jdom ) ;
}
} Eu (Linus) uso o Torus para a maioria dos meus projetos pessoais quando preciso de uma biblioteca de interface do usuário do lado do cliente. Alguns desses projetos incluem:
A API do Torus é uma mistura de interfaces declarativas para definir interfaces e vistas de usuários e padrões imperativos para o gerenciamento do estado, que eu pessoalmente acho que é o melhor equilíbrio dos dois estilos ao criar grandes aplicações. Como prática geral, os componentes devem tentar permanecer declarativos e idempotentes e interagir com modelos de dados / estado por meio de APIs imperativas públicas e estáveis expostas por modelos de dados.
O design da TORUS é inspirado na arquitetura orientada a componentes da React e empresta conceitos comuns do ecossistema React, como a idéia de difundir no DOM virtual antes de renderizar, composição com componentes de ordem superior e misturar CSs e marcar em Javascript para separar as preocupações de cada componente em uma única classe. Mas o Toro se baseia nessas idéias, fornecendo uma APIs de nível inferior mais mínima e menos opinativa e optando por um modelo de dados com estado em vez de uma camada de visualização/controlador que se esforça para ser puramente funcional.
O Torus também empresta da Backbone em seu design de modelos de dados, para registros e lojas, por ter um design orientado a eventos por trás de como as atualizações de dados estão vinculadas a visualizações e outros modelos.
Por fim, a tag de modelo jdom do Torus foi inspirada em HTM e LIT-HTML, ambas as tags de modelo para processar a marcação HTML no Virtual DOM.
A Frontend Development Tooling está em uma tendência a fazer cada vez mais no horário de compilação / tempo de compilação, possibilitando sintaxes e recursos mais ricos, como a adoção de recursos JavaScript e JaScript e JSX. Sitete é um exemplo maravilhoso de como as ferramentas de tempo de compilação podem criar uma maneira de pensar categoricamente diferença sobre a criação de interfaces de usuário.
Torus não tenta ser outra ferramenta de tempo de construção. Um dos objetivos do Torus é ser o mais útil possível em tempo de execução, enquanto sacrifica o mínimo de desempenho e despesas gerais, para que possamos eliminar a etapa de compilação no desenvolvimento. Como resultado, o Torus é a experiência padrão-ouro da prototipagem de idéias da interface do usuário: basta soltar uma tag <script> no documento e começar a escrever. A desvantagem dessa priorização consciente do tempo de execução no tempo de compilação é que alguns recursos que não fazem parte da sintaxe JavaScript simplesmente não são possíveis sem uma etapa de compilação. Notavelmente, a sintaxe do decorador do ECMAScript e a sintaxe JSX não são possíveis, mas seriam úteis, se haja uma etapa compilada na construção de aplicativos de toro. Poderíamos escrever modelos de jddom no JSX, que é sintaticamente muito semelhante, e envolver métodos de atualização do estado e ouvintes de eventos nos decoradores @render e @bind , em vez de chamar this.render() e .bind(this) em todas as instâncias.
A adição de suporte de compilação não está atualmente no roteiro, mas deve ser direta, pois o Torus é um subconjunto de JavaScript moderno. Podemos voltar a abordar esses benefícios marginais da compilação no futuro, especialmente se os decoradores não mostrarem progresso na faixa da proposta.
Estruturas de interface do usuário declarativas semelhantes, como React e PrEACT, introduziram a noção de fragmentos, que é o açúcar de sintaxe para renderizar uma matriz de nós (virtuais) de nós de uma função. Isso ocorre porque, embora um componente retorne uma variedade de nós não faz sentido por si só, geralmente é útil ter funções internas que retornam partes de componentes e vistas como nós sem um elemento de invólucro. O Torus suporta nativamente uma representação da matriz de uma lista de nós - basta embrulhar objetos de juiz em uma matriz! Embora, diferentemente do React, um componente não possa renderizar mais de um nó, a maioria dos casos de uso de fragmentos é coberta por simplesmente poder passar em torno de uma representação de uma lista de nós em uma matriz internamente dentro de um componente, e isso é intuitivamente suportado fora da caixa em Torus.
Eu brinquei com a idéia de modificar a tag de modelo jdom para poder transformar representações de modelos de fragmentos como <>...</> em matrizes de nós. jdom também é capaz de simplesmente analisar elementos adjacentes de nível superior no modelo e devolvê-los em uma única matriz. No entanto, decidi não enviar esses recursos por enquanto, porque acredito que esses casos de uso são adequadamente cobertos por poder devolver as .children de um modelo de jddom, mesmo talvez um envolvido dentro dos marcadores de fragmentos <>...</> Agradeço a explicitação da etapa extra envolvida em devolver uma matriz não tradicional de uma operação de renderização, e acho que o custo ocasional das matrizes retornando como representações intermediárias de partes de uma visão não vale o custo extra.
O Torus usa símbolos, mapas e conjuntos, portanto, é compatível com as versões mais recentes de todos os principais navegadores, exceto o Internet Explorer 11. Em navegadores mais antigos que não suportam o EG Matriz Spread Operators, pode ser necessário transpilar a biblioteca para ES5 usando uma ferramenta como Babel.
Você pode instalar o Torus a partir do NPM como torus-dom . O Torus ainda é considerado beta , e ainda não para uma versão 1.0. Acredito que a API está estável agora e a maioria dos principais insetos foi esmagada, mas não há garantias até 1,0.
npm install --save torus-dom
# or
yarn add torus-dom import { StyledComponent , Record , Store , Router } from 'torus-dom' ;Como alternativa, você também pode importar o torus com:
< script src =" https://unpkg.com/torus-dom/dist/index.min.js " > </ script > A Torus exportará todos os seus globais padrão para window.Torus , para que estejam acessíveis como nomes globais para seus scripts. Isso não é recomendado em aplicativos de produção, mas ótimo para experimentar.
Se você encontrar bugs, abra um problema ou faça uma solicitação de tração com um teste para recriar o bug contra o que você esperava fazer. Se você tiver solicitações de recursos, talvez eu não o honre, porque o Torus está sendo construído principalmente para se adequar às minhas preferências pessoais de fluxo de trabalho e arquitetura. Mas estou aberto a ouvir sua opinião! Portanto, sinta -se à vontade para abrir um problema, com a expectativa de que eu não decida adicionar o recurso ao toro (especialmente se ele inflar o tamanho do feixe ou exigir um transpiler.)
Você pode usar o NPM e o YARN para desenvolver o Torus, mas os scripts da NPM usam fios e o fio é oficialmente apoiado, pois é o que eu uso para desenvolver e construir o toro.
Para construir o toro a partir da fonte, execute
yarn build Isso será executado ./src/torus.js através de uma cadeia de ferramentas personalizada, removendo primeiro qualquer chamada de depuração e executando esse resultado através do WebPack, através dos modos development e production . Ambas as saídas, bem como a versão de baunilha do Torus sem processamento de webpack, são salvas em ./dist/ . A execução yarn clean excluirá quaisquer artefatos de construção, bem como qualquer relatório de cobertura gerado.
O Torus possui um sistema exclusivo para gerar documentação a partir de comentários de código que começam com //> . Para gerar documentos de comentários, execute
yarn docs Os arquivos do DOCs serão gerados em ./docs/ e podem ser visualizados em um navegador da web. Confira a página do Github para este projeto para um exemplo do que esse script gera.
Para executar os testes de unidade do Torus e gerar um relatório de cobertura para coverage/ , execute
yarn testIsso executará o conjunto de testes básicos em uma construção de desenvolvimento do toro. Testes de integração mais abrangentes usando interfaces de usuário completas como os aplicativos TODO estão no roteiro.
Também podemos executar testes na construção da produção, com:
yarn test:prod Isso não gerará um relatório de cobertura , mas executará os testes contra uma construção de produção minificada no dist/torus.min.js para verificar nenhum erro de compilação.
Torus fiados com ESLint, usando uma configuração personalizada. Para executar o linhador, corra
yarn lintOu considere usar um plug -in do editor para ESLint.
