javascript - example - jquery ajax post

Mejores prácticas de Flux: Almacena acciones de despacho, llamadas AJAX en Utilidades de API web.

Question

Entiendo que esta imagen ha sido la última guía de la mayoría, si no de todos, los programadores Flux. Teniendo este flujo en mente, tengo algunas preguntas:

1. ¿Es correcto / altamente recomendable tener todas mis llamadas $.ajax dentro de mis utilidades de API web ?
   • Las devoluciones de llamada llaman a los creadores de acciones, pasando los datos en el proceso
2. Si quiero que mi Tienda haga una llamada AJAX , primero tengo que llamar al Creador de Acciones , ¿verdad? ¿Es fundamentalmente incorrecto llamar a una función en Web API Utils directamente desde la Tienda ?
3. ¿Existe una flecha virtual de un solo lado que se conecta desde Store to Action Creators ?
   • Tengo muchas operaciones que no pasan por vistas
4. ¿Cuáles son las devoluciones de llamada entre Dispatcher y Store ?
5. ¿Cuál es la API web aquí? ¿Es aquí donde aplicarías una API RESTful? ¿Hay algún ejemplo de esto en alguna parte?

6. ¿Está bien tener una lógica involucrada (saber qué Acción enviar) en uno de mis Creadores de Acciones ? Básicamente, esta acción recibe la respuesta de mi llamada AJAX. Este es un fragmento:

   var TransportActions = {
   receiveProxyMessage: function (message, status, xhr) {
   switch (message) {
   case ProxyResponses.AUTHORIZED:
   AppDispatcher.dispatch({
   type: ActionTypes.LOGIN_SUCCESS,
   reply: m
   });
   break;
   case ProxyResponses.UNAUTHORIZED:
   AppDispatcher.dispatch({
   type: ActionTypes.LOGIN_FAIL,
   reply: m
   });
   break;
   ...
   }
   }
   }

He visto muchas respuestas diferentes en línea, pero todavía no estoy seguro de cómo las incorporaría a todas en mi aplicación. TYIA!

Answer 1

1. ¿Es correcto / altamente recomendable tener todas mis llamadas $ .ajax dentro de mis utilidades de API web? Las retrollamadas llaman a los creadores de acciones, pasando los datos en el proceso.

Absolutamente.

2. Si quiero que mi Tienda haga una llamada AJAX, primero tengo que llamar al Creador de Acciones, ¿verdad? ¿Es fundamentalmente incorrecto llamar a una función en Web API Utils directamente desde la Tienda?

Primero, pregúntese por qué su tienda necesita hacer una llamada API. La única razón por la que puedo pensar es que desea almacenar en caché los datos recibidos en las tiendas (esto lo hago).

En las implementaciones de Flux más simples, todas las acciones se crean solo desde la vista y el servidor. Por ejemplo, un usuario visita una vista de "Perfil", la vista llama a un creador de acción profileRequest llama a profileRequest , ApiUtils algunos datos, se crea una ServerAction , la ProfileStore actualiza y la ProfileView hace en consecuencia.

Con el almacenamiento en caché: el ProfileView solicita a ProfileView algún perfil, la tienda no lo tiene, por lo que devuelve un objeto vacío con el estado ''cargando'' y llama a ApiUtils para recuperar ese perfil (y se olvida de él). Cuando finalice la llamada, se ServerAction una ServerAction , la ProfileStore se actualizará, etc. Esto funciona bien. También puede llamar a ActionCreator desde la tienda, pero no veo el beneficio.

MartyJS hace algo similar. Algunas implementaciones de flujo hacen lo mismo con las promesas.

Creo que la parte importante es: cuando los datos vuelven al sistema, se llama a ServerActionCreator con los nuevos datos. Esto luego regresa a las tiendas.

Creo que las tiendas solo deben consultar los datos, todas las acciones que cambian el estado (actualizando cosas) deben ser iniciadas por el usuario (provienen de vistas). Los ingenieros de Facebook escribieron sobre esto aquí: https://news.ycombinator.com/item?id=7719957

3. ¿Existe una flecha virtual de un solo lado que se conecta desde Store to Action Creators?

Si quieres que tus tiendas sean inteligentes, sí. Si quieres que tu aplicación sea simple: no, ve a través de Vistas.

4. ¿Cuáles son las devoluciones de llamada entre Dispatcher y Store?

Estos son los controladores de envío que encuentras en las tiendas. El operador dispara una acción, las tiendas escuchan este evento de fuego y hacen algo con la acción / carga.

5. ¿Cuál es la API web aquí? ¿Es aquí donde aplicarías una API RESTful? ¿Hay algún ejemplo de esto en alguna parte?

Aquí es donde van sus llamadas ajax. Normalmente esto significará un poco de REST API, pero también podría ser websockets o lo que sea. Siempre me ha encantado este tutorial: http://fancypixel.github.io/blog/2015/01/29/react-plus-flux-backed-by-rails-api-part-2/

Descargo de responsabilidad: estas son mis interpretaciones de Flux. Flux en sí mismo no resuelve realmente la obtención de datos, es por eso que han surgido Relay y GraphQL en FB

Answer 2

¿Es correcto / altamente recomendable tener todas mis llamadas $ .ajax dentro de mis utilidades de API web? Las retrollamadas llaman a los creadores de acciones, pasando los datos en el proceso.

Sí, debe colocar toda su solicitud en una única entidad, es decir, los Utilidades de API web. Deben enviar las respuestas para que cualquier tienda pueda elegir actuar sobre ellas.

Hace un tiempo, escribí un blog que mostraba una forma sobre cómo manejar las solicitudes http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

Si quiero que mi Tienda haga una llamada AJAX, primero tengo que llamar al Creador de Acciones, ¿verdad? ¿Es fundamentalmente incorrecto llamar a una función en Web API Utils directamente desde la Tienda?

Esta es una buena pregunta, y por lo que he visto, todos lo hacen un poco diferente. Flux (de Facebook) no proporciona una respuesta completa.

En general, hay dos enfoques que puede tomar aquí:

1. Puedes argumentar que una tienda no debe "pedir" ningún dato, sino simplemente digerir acciones y notificar a la vista. Esto significa que debe disparar acciones de "recuperación" dentro de los componentes si una tienda está vacía. Esto significa que tendrá que verificar en cada vista de escucha de datos si tiene que buscar datos. Esto puede conducir a la duplicación de código, si múltiples vistas escuchan la misma tienda.

2. Las tiendas son "inteligentes" en el sentido de que si les piden datos, verifican si realmente tienen estado para entregar. Si no lo hacen, le dicen a API Utils que busque datos y devuelva un estado pendiente a las vistas.

   Tenga en cuenta que esto "le dice a la API que busque datos" NO es una operación de devolución de llamada, sino una de "disparar y olvidarse". La API enviará acciones una vez que la solicitud regrese.

Prefiero la opción 2 a la opción 1, y he escuchado a Bill Fisher del equipo de Facebook decir que también lo hacen así. (ver comentarios en algún lugar en el blogpost arriba)

así que no, no es fundamentalmente incorrecto llamar al Api directamente desde la Tienda, en mi opinión.

¿Existe una flecha virtual de un solo lado que se conecta desde Store to Action Creators?

Dependiendo de su implementación de Flux, bien podría ser.

¿Cuáles son las devoluciones de llamada entre Dispatcher y Store?

¡Son las únicas funciones que realmente pueden cambiar el estado en una tienda! cada Tienda registra una devolución de llamada con el Dispatcher. Todas las devoluciones de llamada se invocan cada vez que se envía una acción. Cada devolución de llamada decide si tiene que mutar la tienda dado el tipo de acción. Algunas bibliotecas de Flux intentan ocultar este detalle de implementación.

¿Cuál es la API web aquí? ¿Es aquí donde aplicarías una API RESTful? ¿Hay algún ejemplo de esto en alguna parte?

Creo que en la imagen, el rectángulo de la API web representa el servidor real, los API Utils son los que hacen llamadas al servidor (es decir, $ .ajax o superagente). Es muy probable que sea una API RESTful que sirve JSON.

Consejo general:

Flux es un concepto bastante flexible, y las implementaciones exactas cambian de un equipo a otro. Noté que Facebook también ha cambiado algunos enfoques aquí y allá a lo largo del tiempo. El ciclo exacto no está estrictamente definido. Sin embargo, hay algunas cosas bastante "fijas":

1. Hay un despachador que distribuye todas las acciones a todas las tiendas y permite solo una acción a la vez para evitar el infierno de la cadena de eventos.
2. Las tiendas son receptores de acción, y todos los estados se deben cambiar mediante acciones.
3. las acciones son "disparar y olvidar" (¡no hay devoluciones de llamadas!)
4. Las vistas reciben estado de la tienda y disparan acciones

Otras cosas se hacen de forma diferente desde la implementación hasta la implementación