torus-dom )TURUS est un cadre d'interface utilisateur de vue de modèle modéré pour le Web, axé sur le fait d'être minuscule, efficace et exempt de dépendances .
Vous pouvez trouver le? Documentation complète pour Torus ici, sur les pages GitHub .
Torus a également une version annotée et facile à lire de la base de code entière (assez concise), également sur les pages GitHub. Vérifiez-le si vous souhaitez en savoir plus sur la conception des frameworks et comment fonctionne le DOM et les modèles virtuels!
Voici à quoi ressemble Torus en action! Il s'agit d'une application de compteur entièrement fonctionnelle, pas de compilation ou d'étapes de regroupement nécessaires.
Déposez cette balise de script dans votre HTML
< script src =" https://unpkg.com/torus-dom/dist/index.min.js " > </ script >... et charger ce 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 ) ; Torus n'a pas de dépendances de production, ne nécessite aucune étape de construction pour profiter de toutes ses fonctionnalités et pèse moins de 5 kb gzipped, y compris le moteur de modèles, le rendu, le composant et le système d'événements et l'emballage CSS-in-JS. Cela rend simple à adopter et à expédier, pour tout, de rendre un seul composant sur la page à la construction d'applications à grande échelle.
Torus n'est pas conçu pour être la bibliothèque DOM virtuelle la plus rapide (il existe de grandes alternatives comme inferno ), mais les performances et la réactivité sont parmi les principaux objectifs du projet. Tout en restant minuscule, Torus essaie d'être aussi rapide et réactif que possible, en particulier dans le rendu. Combiné avec la petite taille du faisceau, cela rend Torus idéal pour créer des applications Web pour n'importe où, sur n'importe quel appareil.
L'architecture de Torus résume toutes les logiques de rendu et de mise à jour dans le composant lui-même, il est donc sûr de prendre Component#node et de le traiter comme un simple pointeur vers l'élément Root Dom du composant. Vous pouvez le déplacer autour de la page, le prendre dans et sortir du document, l'intégrer dans des composants React ou Vue ou même des composants Web, et autrement l'utiliser partout où un élément DOM traditionnel peut être utilisé. Cela vous permet d'inclure des composants et des applications Torus dans une variété d'architectures frontales.
Combiné avec la petite taille du tore, il est raisonnable d'expédier du tore avec un seul ou quelques composants pour un projet plus grand qui comprend des éléments d'autres cadres, si vous ne voulez pas ou ne pouvez pas expédier une application Torus entière.
Torus ne se préoccupe pas de l'internationalisation, mais en tant que développeurs, nous pouvons utiliser les API disponibles pour nous rendre l'internationalisation possible à l'intérieur de nos composants Torus. Torus expose une grande partie du processus de rendu et du Dom virtuel, le développeur, et nous permet de créer un preprocessor qui peut adopter JDom et le modifier avant qu'il n'atteigne le rendu, afin que nous puissions apporter des modifications au Dom que le rendu voit avec notre propre code. Cela rend le tore hautement extensible et idéal pour i18n. En fait, l'API de préprocesseur des composants est ce qui rend possible les composants Styled() de Torus. ( Styled() ajoute un nouveau nom de classe au jdom avant que le composant ne soit rendu.)
Par exemple, nous pourrions faire un I18nComponent , qui peut agir comme une classe de composants de base pour un projet internationalisé, comme celui-ci.
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 ) ;
}
} J'utilise (Linus) Torus pour la plupart de mes projets personnels lorsque j'ai besoin d'une bibliothèque d'interface utilisateur côté client. Certains de ces projets incluent:
L'API de Torus est un mélange d'interfaces déclaratives pour définir les interfaces et les vues utilisateur, et les modèles impératifs pour la gestion de l'État, que je trouve personnellement le meilleur équilibre des deux styles lors de la création de grandes applications. En tant que pratique générale, les composants devraient essayer de rester déclaratifs et idempotentes, et interagir avec les modèles de données / l'état via des API impératives stables et stables exposées par les modèles de données.
La conception de Torus est inspirée de l'architecture basée sur les composants de React, et emprunte des concepts communs de l'écosystème React, comme l'idée de diffuser dans DOM virtuel avant de rendre, de composition avec des composants d'ordre supérieur et de mélange CSS et de balisage en Javascript pour séparer les préoccupations de chaque composant en une seule classe. Mais Torus s'appuie sur ces idées en fournissant une API de niveau inférieur plus minimal et moins opiniâtre et en optant pour un modèle de données avec état plutôt que sur une couche de vue / contrôleur qui s'efforce d'être purement fonctionnelle.
Torus emprunte également à l'épine dorsale dans sa conception de modèles de données, pour les enregistrements et les magasins, pour avoir une conception axée sur les événements derrière la façon dont les mises à jour des données sont liées aux vues et à d'autres modèles.
Enfin, la balise de modèle jdom de Torus a été inspirée par HTM et LIT-HTML, les deux balises de modèle pour traiter le balisage HTML en Dom virtuel.
L'outillage de développement frontal a été sur la tendance à faire de plus en plus au moment de la construction / compilation, ce qui rend les syntaxes et les fonctionnalités plus riches possibles, comme l'adoption des fonctionnalités JavaScript de la piste de proposition et JSX. Svelte est un merveilleux exemple de la façon dont l'outillage à temps de compilation peut créer une façon catégoriquement différence de penser à créer des interfaces utilisateur.
Torus n'essaie pas d'être un autre outil de construction. L'un des objectifs de Torus est d'être aussi utile que possible lors de l'exécution tout en sacrifiant le moins de performances et de frais généraux que possible, afin que nous puissions éliminer l'étape de compilation dans le développement. En conséquence, Torus est l'expérience en or de prototypage des idées d'interface utilisateur: laissez simplement tomber une balise <script> dans le document et commencez à écrire. L'inconvénient de cette hiérarchisation consciente de l'exécution sur le temps de compilation est que certaines fonctionnalités qui ne font pas partie de la syntaxe JavaScript ne sont tout simplement pas possibles sans étape de compilation. Notamment, la syntaxe du décorateur ECMAScript et la syntaxe JSX ne sont pas possibles, mais seraient utiles, il y avait une étape de compilation dans la création d'applications Torus. Nous pourrions écrire des modèles JDom dans JSX, qui est syntaxiquement très similaire, et envelopper des méthodes de mise à jour et des auditeurs d'événements dans @render et @bind décorateurs plutôt que d'appeler this.render() et .bind(this) à chaque instance.
L'ajout de support de compilation n'est pas actuellement sur la feuille de route, mais il devrait être simple, car Torus est un sous-ensemble de JavaScript moderne. Nous pouvons revenir à la lutte contre ces avantages marginaux de la compilation à l'avenir, surtout si les décorateurs ne montrent aucun progrès dans la piste de proposition.
Des cadres d'interface utilisateur déclaratifs similaires comme React et Preact ont introduit la notion de fragments, qui est du sucre de syntaxe pour rendre un tableau de nœuds DOM (virtuels) d'une fonction. En effet, si un composant renvoie un tableau de nœuds n'a pas de sens seul, il est souvent utile d'avoir des fonctions internes qui renvoient des parties de composants et des vues comme des nœuds sans élément de wrapper. Torus soutient nativement une représentation du tableau d'une liste de nœuds - il suffit d'envelopper des objets JDom dans un tableau! Bien que, contrairement à React, un composant ne peut pas rendre plus d'un nœud, la plupart des cas d'utilisation de fragments sont couverts par le simple fait de passer autour d'une représentation d'une liste de nœuds dans un tableau en interne à l'intérieur d'un composant, et cela est pris en charge intuitivement hors de la boîte dans Torus.
J'ai joué avec l'idée de modifier la balise de modèle jdom pour pouvoir transformer les représentations de modèles de fragments comme <>...</> en tableaux de nœuds. jdom est également capable de simplement analyser les éléments de niveau supérieur adjacents dans le modèle et de les retourner dans un seul tableau. Cependant, j'ai décidé de ne pas expédier ces fonctionnalités pour l'instant, car je pense que ces cas d'utilisation sont adéquatement couverts par la possibilité de retourner les .children d'un modèle JDom, même peut-être un enveloppé à l'intérieur des marqueurs de fragments <>...</> pour la lisibilité, ou simplement retourner un tableau d'objets JDom. J'apprécie l'explicitation de l'étape supplémentaire impliquée dans le retour d'un tableau non traditionnel d'une opération de rendu, et je pense que le coût occasionnel du retour des tableaux en tant que représentations intermédiaires de parties d'une vue ne vaut pas le coût supplémentaire de fonctionnalité.
Torus utilise des symboles, des cartes et des ensembles, il est donc compatible avec les dernières versions de tous les principaux navigateurs, sauf Internet Explorer 11. Sur les navigateurs plus anciens qui ne prennent pas en charge les opérateurs de diffusion de tableau, vous devrez peut-être transpiler la bibliothèque vers ES5 à l'aide d'un outil comme Babel.
Vous pouvez installer Torus à partir de NPM en tant que torus-dom . Le tore est toujours considéré comme bêta , et non à une version 1.0. Je crois que l'API est stable maintenant et la plupart des principaux bugs ont été écrasés, mais aucune garantie jusqu'à 1,0.
npm install --save torus-dom
# or
yarn add torus-dom import { StyledComponent , Record , Store , Router } from 'torus-dom' ;Alternativement, vous pouvez également importer du tore avec:
< script src =" https://unpkg.com/torus-dom/dist/index.min.js " > </ script > Torus exportera tous ses globaux par défaut vers window.Torus , ils sont donc accessibles en tant que noms globaux à vos scripts. Ce n'est pas recommandé dans les applications de production, mais idéal pour l'expérimentation.
Si vous trouvez des bogues, veuillez ouvrir un problème ou mettre une demande de traction avec un test pour recréer le bogue à ce que vous attendez du tore. Si vous avez des demandes de fonctionnalités, je ne pourrais pas nécessairement l'honorer, car Torus est en cours de construction principalement pour convenir à mes préférences de workflow et d'architecture personnelles. Mais je suis ouvert à entendre votre opinion! N'hésitez donc pas à ouvrir un problème, avec l'attente que je ne décide pas d'ajouter la fonctionnalité à Torus (surtout si elle gonflera la taille du bundle ou nécessitera un transpiler.)
Vous pouvez utiliser le NPM et le fil pour développer du tore, mais les scripts NPM utilisent du fil, et le fil est officiellement pris en charge car c'est ce que j'utilise pour développer et construire du tore.
Pour construire du tore à partir de la source, courez
yarn build Cela s'exécutera ./src/torus.js via une chaîne d'outils personnalisée, supprimant d'abord tous les appels de fonction de débogage et exécutant qui résultent via WebPack, via les modes development et production . Les deux sorties, ainsi que la version vanille de Torus sans traitement WebPack, sont enregistrées sur ./dist/ . Running yarn clean supprimera ces artefacts de construction, ainsi que tous les rapports de couverture générés.
Torus a un système unique pour générer de la documentation à partir de commentaires de code qui commencent par //> . Pour générer des documents de commentaires, courez
yarn docs Les fichiers DOCS seront générés sur ./docs/ et seront visibles sur un navigateur Web. Consultez la page GitHub pour ce projet pour un exemple de ce que ce script génère.
Pour exécuter les tests unitaires de Torus et générer un rapport de couverture à coverage/ , exécuter
yarn testCela exécutera la suite de tests de base sur une construction de développement de tore. Des tests d'intégration plus complets utilisant des interfaces utilisateur complètes comme les applications TODO sont sur la feuille de route.
Nous pouvons également effectuer des tests sur la construction de production, avec:
yarn test:prod Cela ne générera pas de rapport de couverture , mais exécutera les tests contre une construction de production minifiée sur dist/torus.min.js pour vérifier qu'aucun bogue de compilation ne s'est produit.
Torus Lints avec Eslint, en utilisant une configuration personnalisée. Pour exécuter le linter, courez
yarn lintou envisagez d'utiliser un plugin d'éditeur pour Eslint.