Om mais en javascript

Modifier juillet 2015: actuellement les plus prometteuses cadre de travail basé sur l'immuabilité est Redux! prendre un coup d'oeil! Ne pas utiliser les curseurs comme l'Om (ni Om Prochaines ne pas utiliser les curseurs).

Les curseurs ne sont pas très évolutive, en dépit de l'aide de CQRS principes décrits ci-dessous, il crée toujours trop passe-partout dans les composants, qui est difficile à maintenir, et ajouter de frottement lorsque vous souhaitez déplacer des composants dans une application existante.

Aussi, il n'est pas clair pour beaucoup de devs sur le moment d'utiliser et de ne pas utiliser des curseurs, et je vois les devs à l'aide de curseurs en place, il ne devrait pas être utilisé, ce qui rend les composants moins réutilisables que les composants prenant de simples accessoires.

Redux utilise connect(), et explique clairement lorsque l'utiliser (conteneur de composants), et quand ne pas le faire (stateless/composants réutilisables). Il résout le standard sur le problème de la transmission des curseurs en bas de l'arbre, et effectue grandement sans trop de compromis.

Que j'ai écrits sur les inconvénients de ne pas utiliser connect() ici

En dépit de ne pas utiliser les curseurs de plus, la plupart des pièces de ma réponse reste valable, à mon humble avis

---

Je l'ai fait moi-même dans notre startup interne cadre atome-réagir

Quelques solutions de rechange en JS sont Morearty, Réagir-curseurs, Omniscient ou Baobab

À l'époque il n'y avait pas immutable-js encore et je n'ai pas fait la migration, toujours à l'aide de la plaine d'objets JS (congelés).

Je ne pense pas qu'à l'aide d'une persistante des structures de données lib qui est vraiment nécessaire, sauf si vous avez de très grandes listes que vous modifier/copier souvent. Vous pouvez utiliser ces projets lorsque vous observez des problèmes de performance que de l'optimisation, mais il ne semble pas être nécessaire pour mettre en œuvre l'Om concepts à l'effet de levier shouldComponentUpdate. Une chose qui peut être intéressante est la partie de immutable-js sur le dosage des mutations. Mais de toute façon je pense toujours que c'est de l'optimisation et n'est pas un préalable essentiel à avoir de très décent spectacles de Réagir avec l'aide de l'Om concepts.

Vous pouvez trouver notre opensource code ici:

C'est le concept d'un Clojurescript Atom qui est une swap de référence à un objet immuable (congelés avec Congélateur). Il a aussi la notion de transaction, dans le cas où vous souhaitez que plusieurs parties de l'état d'être mis à jour automatiquement. Et vous pouvez écouter l'Atome changements (à la fin de la transaction) pour déclencher de Réagir rendu.

Il a le concept de curseur, à l'instar de l'Om (comme une fonctionnelle de la lentille). Il permet de composants pour être en mesure de rendre à l'état, mais aussi de les modifier facilement. C'est pratique pour les formes que vous pouvez faire un lien vers les curseurs directement pour 2 voies de liaison de données:

<input type="text" valueLink={this.linkCursor(myCursor)}/>

Il a le concept de rendu pur, optimisé hors de la boîte, à l'instar de l'Om

---

Différences avec l'Om:

• Pas de locaux de l'état (ce.setState(s) interdite)

Dans l'Atome-Réagir composants, vous ne pouvez pas avoir une composante locale de l'état. Tout l'état est stocké à l'extérieur de Réagir. Sauf si vous avez besoins d'intégration de l'existant bibliothèques Js (vous pouvez toujours utiliser régulièrement Réagir classes), tous à l'état de l'Atome (même pour async/valeurs de chargement) et de l'ensemble de l'application rerenders lui-même de la principale Réagir composant. Réagir est un moteur de template, très efficace, qui transforment un JSON de l'état dans les DOM. Je trouve cela très pratique car je peux me connecter le courant de l'Atome de l'état sur tous les lui rendre, et puis le débogage du code de rendu est tellement facile. Grâce à la sortie de la boîte shouldComponentUpdate il est assez rapide, que je peux même rerender la pleine application à chaque fois que l'utilisateur appuie sur une nouvelle touche du clavier sur une saisie de texte, ou passez la souris sur un bouton de la souris. Même sur un téléphone mobile!

• Opiniâtre façon de gérer l'état (inspiré par le CQRS/EventSourcing et Flux)

Atome-Réagir ont une très opiniâtre façon de gérer l'état inspiré par Flux et CQRS. Une fois que vous avez tous votre état en dehors de Réagir, et vous avez un moyen efficace de les transformer en JSON état aux DOM, vous trouverez que le reste de la difficulté est de gérer votre JSON état.

Certaines de ces difficultés rencontrées sont:

1. Comment gérer asynchrone valeurs
2. Comment gérer les effets visuels nécessitant DOM changements (survolés par la souris ou de se concentrer par exemple)
3. Comment organiser votre état pour qu'il évolue sur une grande équipe
4. Où le feu les requêtes ajax.

Donc je me retrouve avec la notion de Magasin, inspiré par le Facebook Flux architecture.
Le point est que je n'aime vraiment pas le fait que d'un magasin de Flux peut effectivement dépendre d'une autre, l'obligeant à orchestrer des actions par l'intermédiaire d'un complexe répartiteur. Et vous finissez par avoir à comprendre l'état de plusieurs magasins pour être en mesure de rendre leur.

Dans l'Atome-Réagir, le Magasin est juste un "espace de noms réservés" à l'intérieur de l'etat tiennent par l'Atome.

Donc je préfère tous les magasins seront mis à jour à partir d'un flux d'événements de ce qui s'est passé dans l'application. Chaque magasin est indépendant, et de ne pas accéder aux données d'autres magasins (exactement comme dans une architecture CQRS, lorsque les éléments de recevoir exactement les mêmes événements, sont hébergés dans de différentes machines, et de gérer leur propre état comme ils le souhaitent). Cela rend plus facile à maintenir que vous pouvez développer un nouveau composant, vous avez juste à comprendre que l'état d'un magasin. Ce en quelque sorte conduit à la duplication des données, parce que maintenant plusieurs magasins peut-être de garder les mêmes données dans certains cas (par exemple, sur un SPA, il est probable que vous voulez l'id de l'utilisateur courant dans de nombreux endroits de votre application). Mais si de 2 magasins mettre le même objet dans leur état (en provenance d'un événement), ce fait ne consomment pas de données supplémentaires comme c'est toujours 1 objet référencé par deux fois dans les 2 magasins différents.

À comprendre les raisons de ce choix, vous pouvez lire les blogs de CQRS chef de file Udi Dahan,L'Illusion De La Réutilisation et des autres au sujet de Composants Autonomes.

Donc, un magasin est juste un morceau de code qui reçoivent les événements et les mises à jour de ses espaces de l'état dans l'Atome.

Cela déplace la complexité de la gestion de l'état vers un autre calque. Maintenant, le plus difficile est de définir avec précision quels sont vos événements d'application.

---

Noter que ce projet est encore très instable et sans-papiers/pas bien testé. Mais nous l'utilisons déjà ici, avec un grand succès. Si vous voulez discuter de ce sujet ou y participer, vous pouvez me joindre sur IRC: Sebastien-L dans #reactjs.

C'est ce que l'on ressent à développer un SPA avec ce cadre. Chaque fois qu'il est rendu, avec le mode de débogage, vous devez:

• Le temps qu'il a fallu pour transformer le JSON pour Virtual DOM et de l'appliquer à la vraie DOM.
• L'état connecté pour vous aider à déboguer votre application
• Le temps perdu grâce à React.addons.Perf
• Un chemin diff par rapport à l'état précédent de facilement savoir ce qui a changé

Cochez cette capture d'écran:

Quelques avantages que ce type de cadre peut apporter que je n'ai pas exploré encore beaucoup de choses:

• Vous vraiment annuler/refaire intégré (il a travaillé hors de la boîte dans ma production réelle application, pas seulement un TodoMVC). Cependant, à mon humble avis, la plupart des actions dans de nombreuses applications sont en fait produire des effets secondaires sur un serveur, donc il ne fait pas toujours sens pour inverser l'INTERFACE utilisateur à un état antérieur, que l'état précédent serait vicié

• Vous pouvez enregistrer des instantanés de l'état, et de les charger dans un autre navigateur. CircleCI a montré en action sur cette vidéo

• Vous pouvez enregistrer des "vidéos" de sessions utilisateur dans un format JSON, de les envoyer à votre serveur d'arrière-plan pour le débogage ou la relecture de la vidéo. Vous pouvez flux en direct d'une session utilisateur à un autre navigateur assistance à l'utilisateur (ou d'espionnage pour vérifier vivre UX comportement de vos utilisateurs). Si l'etat d'envoi peut être assez cher, mais probablement formats comme Avro peut vous aider. Ou si votre application en cours est sérialisable, vous pouvez simplement les flux de ces événements. J'ai déjà mis en place facilement dans le cadre et il fonctionne dans ma production de l'application (juste pour le fun, il ne transmet rien pour le backend encore)

• Temps à voyager de débogage ca sera possible, comme dans l'ORME

J'ai fait une vidéo de la "session utilisateur en JSON" en fonction de pour ceux qui sont intéressés.