Redux: Propuesta: cambiar el nombre de "tiendas" a "reductores"

-1 la curva de aprendizaje en este repositorio ya se siente empinada. No lo hagamos más empinado mediante la introducción de nueva terminología para los nuevos usuarios de flux.

Internamente se pueden llamar reductores, mantenlos públicamente como tiendas para que sea más fácil asimilarlos.

Honestamente, creo que es más confuso como está ahora. Totalmente anecdótico, pero he tenido a varias personas en la vida real que se han equivocado pensando en cómo una "tienda" podría ser apátrida.

Las principales características de las "tiendas" en Flux tradicional son que 1) mantienen el estado y 2) emiten eventos de cambio. Ninguno de los cuales es cierto en Redux.

Estoy de acuerdo en que necesitamos aclarar la terminología y, en algunos casos, encontrar mejores nombres.
Creo que como primer paso debería haber algo de JSDoc, luego una sección de terminología también ayudaría.
En general tenemos que mantener un cierto nivel de coherencia.

Me pregunto si hay un término que no suena como FP pero que tampoco es una "tienda".
Dominios?

OTOH ya se llama Redux, por lo que al menos "reductor" suena relacionado.

¿Qué tal las "actualizaciones escalonadas", o "steppers", que hacen que su estado avance un paso más? He visto que esto se usa en la literatura de Elm, con una función llamada step , update o next

Los dominios contienen el equipaje de node.js.

No son tiendas en cómo funcionan, pero aún colocas tu lógica de estado allí de manera muy similar a las tiendas de flujo. Son gerentes estatales, como se supone que son las tiendas de flujo.

Sin embargo, Reducers está bien si estás interesado en cambiar su nombre.

Especialmente porque "reductor" es una descripción precisa de lo que realmente son :)

Actualizadores? Suena descriptivo + menos snob que reductores.

También me gusta reducer

Supongo que no veo por qué "reductor" es snob. ¿No es mejor usar el término real que inventar uno nuevo que sea menos descriptivo?

Supongo que ambos pueden ser válidos, y depende de qué punto de vista lo veas: un _reductor_ de acciones (en estado), o un _actualizador_ de estado.

"Updater" implica que es mutativo. "Reducer" deja en claro que está devolviendo un nuevo estado, no modificando el anterior.

Ese es un punto fuerte a favor, creo, puede ayudar con el problema de que redux no funciona correctamente con mutaciones.

Aprecio la necesidad de que Redux sea amigable para las personas que no están familiarizadas con FP, pero podemos resolverlo con una mejor documentación. Me gustan los documentos actuales, pero a primera vista son un poco abrumadores. Un buen sitio de documentos que ponga en primer plano las cosas familiares (creadores de acciones, lógica reductora) sobre las cosas avanzadas (middleware, recarga en caliente) sería muy útil.

Y, sin embargo, a juzgar por el rápido crecimiento de lo siguiente aquí, debemos estar haciendo algo bien :)

Estoy dispuesto a cambiar "Tiendas" a "Reductores" si esto sucede junto con mejores documentos.

El elemento esencial es preservar la vibra de "es como Flux pero mejor, no se preocupe". No quiero que la gente piense que es similar a Reflux o algo así, que suena como Flux pero rompe algunas de sus bonitas propiedades. Tampoco quiero que piensen que necesitan aprender FP. Mientras podamos mantenerlo así, estoy de acuerdo con este cambio.

Sugerencia de la que estoy menos seguro: si cambiamos el nombre de la clase Redux a Store (piénselo: sus dos propósitos son mantener el estado y emitir eventos de cambio), entonces la API de nivel superior se convierte en:

const store = createStore(reducers);

<Provider store={store} />

Esto comunica la idea bastante bien, creo. Los reductores son donde va la lógica de su tienda, pero no son tiendas en sí mismas.

Me gusta esto aunque store.dispatch siente mal entonces.

Sí, eso es lo único que realmente no me gusta, pero los otros métodos tienen sentido: store.getState() , store.setState() , store.subscribe()

Ahora que lo pienso, realmente no estamos “despachando” nada.
Uf, nombrar es un agujero de conejo.

Ok, entonces lo que tenemos hasta ahora es:

• acción (creadores)
• (tienda) reductor
• funciones de middleware
• funciones de devolución de llamada (oyente)
• algo que desencadena la cadena de llamadas de funciones (llamado despachador)
• algo que mantiene el estado mutable (con setters y getters)

¿Quizás podamos dar un paso atrás y repensar el nombre?

Quizás store.dispatch no sea tan malo. Simplemente podemos explicar que en lugar de muchas tiendas, tenemos una sola tienda, y tú la compones desde Reductores. Sin tiendas = no es necesario un despachador por separado, por lo que dispatch está disponible directamente en la tienda.

@gaearon estoy de acuerdo.

@emmenko Buen resumen. Cualquier desglose de terminología debe distinguir entre _creadores de acciones_ y _acciones_. También debe distinguir entre _dispatcher_ o _dispatch strategy_, que abarca middleware + reductores, así como el método _dispatch_ que desencadena un _ciclo de despacho_.

Hagámoslo:

• Cambiar el nombre de las tiendas a Reductores
• Cambie el nombre de la "instancia de Redux" a Store según https://github.com/gaearon/redux/issues/137#issuecomment -113252359
• Explique que si entrecierra los ojos en las tradicionales Flux Stores, verá reductores atrapados en ellas.

¿Alguien quiere liderar el nuevo esfuerzo de documentación? Necesitará algo de estructuración: un glosario, un archivo README, un sencillo tutorial de "puesta en marcha" y tal vez una guía más detallada de "decisiones de diseño".

@gaearon Me

Gracias: +1:

Me ofreceré como voluntario para liderar esto

¡Gracias! : +1:: +1:: +1:

Personalmente, como resultado final, realmente me gustaría tener un sitio web generado automáticamente con:

• empezando
• tutoriales
• ejemplos en vivo

... y como una característica agradable:

• documentación generada a-la docco (por ejemplo: como jasmine ) para que el código fuente se explique claramente

Pero comenzar con markdown y jsdoc es, por supuesto, un primer paso;)

Bien, creo que el primer paso es obtener los documentos escritos en formato Markdown, luego podemos transferirlos a un sitio de documentos realmente agradable. : +1: también para JSDoc. Voy a hacer una última puñalada en https://github.com/gaearon/redux/pull/87 esta noche, pero no estoy seguro de que las anotaciones de Flow valgan la pena en este punto, a menos que eliminemos la base de código de la sobrecarga de funciones. (O a menos que alguien me enseñe cómo escribirlos correctamente sin que Flow se queje).

Supongo que Flow no es un cajero automático prioritario.

+1 para las tiendas que se denominan reductores.

No me ha gustado llamar a estas tiendas de cosas más declarativas y apátridas.

Me gustan las nuevas ideas de nombres. También propondría cambiar el nombre de Connector a algo como Subscription . Connector es muy genérico, y aunque entiendo que está conectando el estado y el despachador de redux con sus hijos, creo que una suscripción es una mejor descripción de lo que está sucediendo. Es un poco exagerado tener un despachador junto con su suscripción, pero creo que está bien.

-1 para las tiendas que se llaman reductores, como nombre no es muy intuitivo para los nuevos usuarios (al menos para aquellos que no tienen experiencia en programación funcional). Quizás Updater o Transformer serían mejores, o Store Updater si quisiéramos ser más explícitos al respecto.

Se han sugerido “Transformers” bastantes veces. No sugiere una naturaleza mutable como los Actualizadores, es más accesible que los Reductores y no tiene la connotación de "almacenamiento" de Tiendas.

¿Qué te parece Transformers?

+1 para reductores

Como señaló @faassen en Twitter, un buen argumento para los "reductores" es volver a llamar al nombre del proyecto. Tenemos la oportunidad de decir “Esto es como Flux, pero hay una sola tienda. Al igual que puedes componer tu aplicación en componentes de React, en Redux, compones esa Tienda a partir de Reductores. Se denominan Reductores porque su función de coincidencias de firma pasó a [].reduce() : (state, action) => state . Bla bla bla"

propagación angular como la pólvora y usa palabras como

• directiva
• aislar
• transcluir

Ignorar programar, transformar y reducir son cosas diferentes. Elegiría el nombre más exacto.

Si no almacenan datos, no los llame tiendas.

¿Te estás transformando de una forma a otra o estás reduciendo de muchos valores a uno?

Transformador => mapa
Reductor => reducir

Me suena a reducir.

¡Yo también estoy por reducers ! : +1:

Inspírate en Elm. https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

La mejor palabra sería update . Tienda es una tontería, siempre ha sido "Modelo". No es necesario reinventar la rueda ni confundir a la gente.

Mi problema con llamarlos actualizadores es que la gente podría pensar que se supone que son mutantes. Si el nombre puede ayudar a aclarar la naturaleza no mutativa, sería una gran ventaja.

¿Te estás transformando de una forma a otra o estás reduciendo de muchos valores a uno?

Estoy acumulando. "Cómo una acción convierte un estado en el siguiente estado". Conceptualmente, están reduciendo muchas acciones desde el estado inicial (indefinido), y la memorización es solo una optimización.

Transformador de estado

Trate de evitar reinventar / redescubrir tanto como sea posible. La gente lo ha estado llamando reduce , scan , fold y update .

reducer parece ser preciso desde una perspectiva de javascript ...
No ve el valor para nombrarlo a partir de un concepto de otro idioma, incluso si es más preciso.

No tenga una postura firme sobre lo que debería ser, pero en mi opinión, debería ser algo que represente con mayor precisión el tipo de cálculo. Si es una palabra umfaliar para la mayoría de los programadores, entonces puede compensarse con la documentación.

@vramana no es un map , es un reduce , ya que toma los state previamente acumulados y un nuevo action y devuelve un nuevo state .

Si tuviera una matriz de todas las acciones de su aplicación, usaría esta función para reducirla al estado final de la aplicación:

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

Ahora, lo que realmente tiene es un stream de actions en el tiempo, que es conceptualmente lo mismo que una matriz, pero en el tiempo (puede reducirlo a un stream de state s).

Me gusta pensar en ello como una proyección (de un registro de eventos a una estructura de datos).
La gente de DB solía llamar a esto "vistas materializadas".

Me gusta reducir o doblar, es bien entendido por diferentes comunidades.

Prefiero Transformers a Reducers: está claro lo que significa por el uso normal de la palabra en inglés.

Reductores.
Primero, es una biblioteca javascript y javascript tiene [].reduce(reducer, initialState) .
En segundo lugar, Redu (cer) x ya está en el nombre de la biblioteca.
En tercer lugar, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , otras personas y bibliotecas utilizarán el término 'reductores'.

Reducer es preciso y tiene un precedente en Vanilla JS. No estoy seguro de cómo se podría mejorar.

Reductores será entonces.

(Siga el progreso en el n. ° 140)

De vez en cuando encuentro viejas discusiones llamándolas "tiendas" y me maravillo de lo ridículamente confuso que fue en retrospectiva.

"contenedor estatal"?

Sí, este fue un buen cambio :)