Redux: Proposition : Renommer "magasins" en "réducteurs"

-1 la courbe d'apprentissage sur ce repo semble déjà raide. Ne le rendons pas plus raide en introduisant une nouvelle terminologie pour les nouveaux utilisateurs de flux.

En interne, ils peuvent être appelés réducteurs, gardez-les publiquement en tant que magasins afin qu'il soit plus facile de les surveiller.

Je pense honnêtement que c'est plus déroutant comme c'est maintenant. Totalement anecdotique, mais j'ai eu plusieurs personnes IRL qui ont tout foiré en pensant à la façon dont un "magasin" pourrait être apatride.

Les principales caractéristiques des "magasins" dans Flux traditionnel sont qu'ils 1) conservent un état et 2) émettent des événements de changement. Ni l'un ni l'autre n'est vrai dans Redux.

Je conviens que nous devons clarifier la terminologie et, dans certains cas, trouver une meilleure dénomination.
Je pense que dans un premier temps, il devrait y avoir du JSDoc, puis une section de terminologie serait également utile.
En général, nous devons maintenir un certain niveau de cohérence.

Je me demande s'il y a un terme qui ne sonne pas FP mais qui n'est pas non plus un "magasin".
Domaines?

OTOH ça s'appelle déjà Redux donc au moins les sons "réducteurs" sont liés.

Que diriez-vous des « mises à jour par étapes » ou des « pas à pas », qui font avancer votre état d'un pas. J'ai vu cela être utilisé dans la littérature Elm, avec une fonction appelée step , update , ou next

Les domaines contiennent des bagages node.js.

Ce ne sont pas des magasins dans leur fonctionnement, mais vous y mettez toujours votre logique d'état, un peu comme des magasins de flux. Ce sont des gestionnaires d'État, comme les magasins de flux sont censés l'être.

Les réducteurs conviennent si vous souhaitez changer son nom.

Surtout parce que "réducteur" est une description précise de ce qu'ils sont réellement :)

Mises à jour ? Cela semble descriptif + moins snob que les réducteurs.

J'aime aussi reducer

Je suppose que je ne vois pas pourquoi "réducteur" est snob. Ne vaut-il pas mieux utiliser le terme actuel que d'en inventer un nouveau moins descriptif ?

Je suppose que les deux peuvent être valides, et cela dépend de quel point de vue vous le voyez : un _réducteur_ d'actions (dans l'état), ou un _updater_ d'état.

"Updater" implique que son mutatif. "Réducteur" indique clairement que vous retournez un nouvel état, sans modifier l'ancien.

C'est un point fort en faveur, je pense, peut aider à résoudre le problème du redux qui ne fonctionne pas correctement avec les mutations

J'apprécie la nécessité de garder Redux convivial pour les personnes qui ne sont pas familiarisées avec FP, mais nous pouvons résoudre ce problème avec une meilleure documentation. J'aime les documents actuels, mais à première vue, ils sont un peu écrasants. Un bon site de documentation qui met en avant les éléments familiers (créateurs d'action, logique de réduction) par rapport aux éléments avancés (intergiciel, rechargement à chaud) serait très utile.

Et pourtant, à en juger par la croissance rapide de ce qui suit ici, nous devons faire quelque chose de bien :)

Je suis prêt à changer « Magasins » en « Réducteurs » si cela se produit avec de meilleurs documents.

L'élément essentiel est de préserver l'ambiance « c'est comme Flux mais en mieux, ne vous inquiétez pas ». Je ne veux pas que les gens pensent que c'est similaire à Reflux ou quelque chose comme ça, qui ressemble à Flux mais casse certaines de ses belles propriétés. Je ne veux pas non plus qu'ils pensent qu'ils doivent apprendre la PF. Tant que nous pouvons le garder ainsi, je suis d'accord avec ce changement.

Suggestion dont je suis moins sûr : si nous renommons la classe Redux en Store (pensez-y : ses deux objectifs sont de conserver l'état et d'émettre des événements de changement), alors l'API de niveau supérieur devient :

const store = createStore(reducers);

<Provider store={store} />

Cela communique assez bien l'idée, je pense. Les réducteurs sont là où va votre logique de magasin, mais ce ne sont pas des magasins eux-mêmes.

J'aime ça bien que store.dispatch se sente mal alors.

Oui, c'est la seule chose que je n'aime pas vraiment, mais les autres méthodes ont du sens : store.getState() , store.setState() , store.subscribe()

Maintenant que j'y pense, nous n'envoyons pas vraiment quoi que ce soit.
Ugh, nommer est un terrier de lapin.

Ok, donc ce que nous avons jusqu'à présent sont:

• action (créateurs)
• (magasin) réducteur
• fonctions middleware
• fonctions de rappel (écouteur)
• quelque chose qui déclenche la chaîne d'appel de fonctions (appelée répartiteur)
• quelque chose qui détient l'état mutable (avec setters et getters)

Peut-être pouvons-nous prendre du recul et repenser le nom ?

Peut-être que store.dispatch n'est pas trop mal. Nous pouvons simplement expliquer qu'au lieu de nombreux magasins, nous avons un seul magasin et que vous le composez à partir de réducteurs. Pas de magasins = pas besoin d'un répartiteur séparé, donc dispatch est disponible directement sur Store.

@gaearon je suis d'accord.

@emmenko Bon résumé. Toute ventilation terminologique doit faire la distinction entre les _créateurs d'actions_ et les _actions_. Il convient également de faire la distinction entre le _dispatcher_ ou _dispatch strategy_, qui englobe middleware + réducteurs, ainsi que la méthode _dispatch_ qui déclenche un _cycle de distribution_.

Faisons cela:

• Renommer les magasins en réducteurs
• Renommez « l'instance Redux » en Store selon https://github.com/gaearon/redux/issues/137#issuecomment -113252359
• Expliquez que si vous louchez dans les magasins de flux traditionnels, vous verrez des réducteurs piégés dedans

Quelqu'un veut-il diriger le nouvel effort de documentation ? Cela nécessitera une certaine structuration : un glossaire, un fichier README, un simple didacticiel « de mise en route » et peut-être un guide plus détaillé sur les « décisions de conception ».

@gaearon Je me

Merci :+1:

Je vais me porter volontaire pour diriger ça

Merci! :+1: :+1: :+1:

Personnellement, comme résultat final, j'aimerais vraiment avoir un site Web généré automatiquement avec :

• commencer
• tutoriels
• exemples vivants

... et en tant que fonctionnalité intéressante :

• documentation générée a-la docco (ex: like jasmine ) afin que le code source soit clairement expliqué

Mais commencer par markdown et jsdoc est bien sûr une première étape ;)

D'accord, je pense que la première étape consiste à écrire les documents sous forme Markdown, puis nous pouvons les porter sur un très bon site de documentation. :+1: pour JSDoc aussi. Je vais essayer un dernier coup sur https://github.com/gaearon/redux/pull/87 ce soir, mais je ne suis pas sûr que les annotations Flow en valent la peine à ce stade, à moins que nous ne débarrassions la base de code de la surcharge de fonctions. (Ou à moins que quelqu'un m'apprenne à les taper correctement sans que Flow se plaigne.)

Je suppose que Flow n'est pas un guichet automatique prioritaire.

+1 pour les magasins s'appelant réducteurs.

Je n'aimais pas appeler ces magasins d'objets plus déclaratifs et apatrides.

J'aime les nouvelles idées de nom. Je proposerais également de renommer Connector en quelque chose comme Subscription . Connector est très générique, et même si je comprends qu'il connecte l'état et le répartiteur de redux à ses enfants, je pense qu'un abonnement est une meilleure description de ce qui se passe. C'est un peu exagéré que vous ayez un répartiteur avec votre abonnement, mais je pense que ça va.

-1 pour les magasins appelés réducteurs, ce nom n'est pas très intuitif pour les nouveaux utilisateurs (du moins ceux qui n'ont pas de connaissances en programmation fonctionnelle). Peut-être qu'Updater ou Transformer serait mieux, ou Store Updater si nous voulions être plus explicites à ce sujet.

Les « transformateurs » ont été suggérés à plusieurs reprises. Il ne suggère pas une nature mutable comme les Updaters, est plus accessible que les Reducers et n'a pas la connotation de « stockage » de Stores.

Aimez-vous les transformateurs ?

+1 pour les réducteurs

Comme l'a noté @faassen sur Twitter, un bon argument pour les « réducteurs » est de rappeler le nom du projet. Nous avons la possibilité de dire « C'est comme Flux, mais il n'y a qu'un seul magasin. Tout comme vous pouvez composer votre application en composants React, dans Redux, vous composez ce magasin à partir de réducteurs. Ils sont appelés réducteurs car leur signature correspond à la fonction passée à [].reduce() : (state, action) => state . Bla bla bla"

propagation angulaire comme une traînée de poudre et utilise des mots comme

• directif
• isoler
• transclure

Ignorer la programmation, transformer et réduire sont des choses différentes. Je choisirais le nom qui est le plus précis.

S'ils ne stockent pas de données, ne les appelez pas des magasins.

Passez-vous d'une forme à une autre ou réduisez-vous de plusieurs valeurs à une seule ?

Transformateur => carte
Réducteur => réduire

Sonne comme réduire pour moi.

Je suis pour reducers aussi ! :+1:

Inspirez-vous d'Elm. https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

Le meilleur mot serait update . Store est un non-sens, il a toujours été "Modèle". Pas besoin de réinventer la roue ou de semer la confusion chez les gens.

Mon problème à les appeler des mises à jour, c'est que les gens pourraient penser qu'ils sont censés être mutants. Si le nom peut aider à clarifier la nature non-mutative, ce serait un énorme bonus.

Passez-vous d'une forme à une autre ou réduisez-vous de plusieurs valeurs à une seule ?

j'accumule. « Comment une action transforme un état en un état suivant. » Conceptuellement, ils réduisent de nombreuses actions par rapport à l'état initial (non défini), et la mémorisation n'est qu'une optimisation.

Transformateur d'état

Essayez d'éviter autant que possible de réinventer/redécouvrir. Les gens l'ont appelé reduce , scan , fold , et update .

reducer semble être exact d'un point de vue javascript...
Ne voyez pas la valeur pour le nommer à partir d'un concept d'un autre langage, même si c'est plus précis.

N'ayez pas une position ferme sur ce que cela devrait être, mais selon l'OMI, cela devrait être quelque chose qui représente le plus précisément le type de calcul. S'il s'agit d'un mot familier à la plupart des programmeurs, cela peut être compensé par la documentation.

@vramana ce n'est pas un map , c'est un reduce , car il prend les state précédemment accumulés et un nouveau action et renvoie un nouveau state .

Si vous aviez un tableau de toutes les actions de votre application, vous utiliseriez cette fonction pour la réduire à l'état final de l'application :

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Maintenant, ce que vous avez vraiment est un stream de actions dans le temps, ce qui est conceptuellement le même qu'un tableau, mais dans le temps (vous pouvez le réduire en un stream de state s).

J'aime y penser comme une projection (d'un journal d'événements vers une structure de données).
Les gens de la DB appelaient cela des "vues matérialisées".

J'aime réduire ou plier, c'est bien compris par les différentes communautés

Je préfère de loin les transformateurs aux réducteurs : c'est clair ce que cela signifie d'après l'usage anglais normal du mot.

Réducteurs.
Tout d'abord, c'est la bibliothèque javascript et javascript a [].reduce(reducer, initialState) .
Deuxièmement, Redu(cer)x est déjà dans le nom de la bibliothèque.
Troisièmement, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , d'autres personnes et bibliothèques utiliseront le terme « réducteurs ».

Le réducteur est précis et a un précédent dans vanilla JS. Je ne sais pas comment cela pourrait être amélioré.

Réducteurs ce sera alors.

(Suivez les progrès dans #140)

De temps en temps, je trouve de vieilles discussions les appelant « magasins » et je m'émerveille de voir à quel point c'était ridiculement déroutant avec le recul.

« conteneur d'état » ?

Oui c'était un bon changement :)