Al final hay un resumen de TL; DR.
Realmente no puedo señalarle un buen recurso para esto ya que no he encontrado uno. Sin embargo, no todo está perdido. Ya tiene experiencia en el desarrollo de aplicaciones a gran escala y llevar este conocimiento al espacio del navegador no requiere mucha reflexión.
En primer lugar, a menos que su aplicación sea realmente trivial, no comenzaría a refacturar toda la base de códigos de inmediato ya que seguramente habrá un sinfín de casos en los que aún no ha pensado.
Primero diseñe la arquitectura central del sistema que desea. En tu caso, probablemente quieras que todas tus solicitudes AJAX pasen por un punto. Seleccione la interfaz XHR de jQuery o YUI y escriba una envoltura a su alrededor que tome una opción hash.Todas las llamadas XHR que escriba para el nuevo código pasan por allí. Esto le permite cambiar el marco que realiza las llamadas XHR en cualquier momento con otro marco o el suyo propio.
A continuación, armonice el protocolo del cable. Recomiendo usar las solicitudes JSON y POST (las solicitudes POST tienen el beneficio adicional de que las presentaciones FORMAS no se almacenen en caché). Haga una lista de los diferentes tipos de solicitudes/respuestas que necesita. Para cada una de estas respuestas, crea un objeto JS para encapsularlas. (Por ejemplo, la respuesta de envío de formulario se devuelve al llamador como un objeto FormReponse que tiene funciones de acceso para los errores de validación, etc.). La sobrecarga de JS para esto es totalmente trivial y hace que sea fácil cambiar el protocolo JSON en sí mismo sin pasar por su código de widget para cambiar el acceso del JSON sin formato.
Si tiene que lidiar con muchos formularios, asegúrese de que todos tengan la misma estructura para que pueda usar un objeto JS para serializarlos. La mayoría de los marcos parecen tener varias funciones nativas para hacer esto, pero yo recomendaría rodar el suyo para que no tenga que lidiar con las deficiencias.
El valor comercial agregado en este punto es, por supuesto, cero porque todo lo que tiene es el comienzo de una manera sensata de hacer las cosas y aún más código JS para cargar en su aplicación.
Si tiene un nuevo código para escribir, escríbalo en las API que acaba de implementar. Esa es una buena forma de ver si no estás haciendo nada realmente estúpido. Mantenga el otro JS como está por ahora, pero una vez que tenga que corregir un error o agregar una función allí, refactorice ese código para usar sus nuevas API. Con el tiempo, descubrirá que el código importante se está ejecutando en sus API y que muchas otras cosas se volverán obsoletas lentamente.
No exageres al reinventar la rueda. Mantenga esta nueva estructura limitada a la interacción de datos y el cable HTTP y use su marco JS primario para manejar cualquier cosa relacionada con DOM, caprichos del navegador, etc.
Configure también un objeto logger global y no use la consola directamente. Haga que su objeto logger use la consola o un registrador DOM personalizado o lo que sea que necesite en diferentes entornos. Eso hace que sea fácil construir en niveles de registro personalizados, filtros de registro, etc. Obviamente, debe configurar su entorno de compilación para eliminar ese código para las compilaciones de producción (¿tiene un proceso de compilación para esto, correcto?)
Mi favorito personal para el diseño de código fuente JS relativamente sano y el espacio de nombres es el marco Dojo. Las definiciones de objeto relativas a su espacio de nombres tienen relaciones obvias con su ubicación en el disco, existe un sistema de compilación para compilaciones personalizadas, módulos de terceros, etc. El sistema de dependencia/compilación Dojo depende de dojo.require y dojo.provide declaraciones en el código. Cuando se ejecuta en la fuente dojo.require, la instrucción activará la carga de bloqueo del recurso en cuestión. Para la producción, el sistema de compilación sigue estas instrucciones e inserta el recurso en el paquete final en esa ubicación. La documentación es un poco escasa, pero definitivamente es un buen comienzo para la inspiración.
El TL; DR respuesta es,
- que todas las llamadas XHR pasan por una única interfaz
- No pase los datos de respuesta primas de nuevo a niveles más altos
- hacer refactorización gradual de código existente
- armonizar el protocolo de cable
- uso el poder dinámico de JS para la construcción de código proxy de peso ligero
- structu código Sane los gráficos re y call tienen el mismo aspecto en JS que en otros idiomas
Gracias por su gran comentario. De hecho, ya hice algunas de las cosas que dijiste. Por ejemplo, todas mis llamadas ajax pasan por una única interfaz, pero tengo una para publicación y otra para get. El problema con hacer publicaciones es que realmente tengo que programar los deserializadores usando Jackson a menos que algo haya cambiado ... lo cual es terriblemente lento :(Por ejemplo, si javascript envía activeQuestionId, quiero que Spring lo asigne a un objeto ActiveQuestion de la base de datos ... pero deshabilitan a los editores de propiedades para la deserialización json ... lo cual no tiene sentido ya que es parte del mvc. – egervari
Así que la elección para mí a menudo se convierte en, "Use get para una programación fácil, y use post cuando absolutamente tenga que enviar una estructura de datos JSON compleja porque get simplemente no funcionará " – egervari
Creo que una de las grandes cosas con las que estoy luchando es la reutilización de código. Todos mis requisitos parecen ser ligeramente diferentes, por lo que el javascript de cada página termina siendo enorme. Estoy tratando de refactorizarlo, pero parece que no puedo obtener un modelo de programación agradable y fácil. ¿Es eso solo la naturaleza de la bestia? – egervari