Posteriormente a consultar con especialistas en el tema, programadores de varias áreas y maestros hemos dado con la respuesta al dilema y la compartimos en esta publicación.
Solución:
Combinar VueJs y Razor Pages no es necesariamente algo malo, ¡puede ser genial!
Utilizo Vue con maquinilla de afeitar para páginas que no son de SPA y las dos funcionan bien juntas. Elijo usar Vue cargándolo a través de una etiqueta de script desde un CDN y no aprovecho el uso de WebPack para transpilar, simplemente escribo mi código en (jadeo) ES5. Elegí este enfoque por las siguientes razones.
- El uso de páginas de Razor en lugar de un SPA ayuda en SEO y en la clasificación de los motores de búsqueda de las páginas públicas.
- La carga de Vue directamente desde un CDN elimina una pila completa de tecnología centrada en Webpack de la curva de aprendizaje, lo que hace que sea mucho más fácil para los nuevos desarrolladores ponerse al día con el sistema.
- El enfoque aún proporciona la bondad reactiva al desarrollo de la interfaz de usuario que Vue trae inherentemente a la mesa.
- Al mantener el “modelo de página”, el código que ofrece la funcionalidad del sitio se agrupa lógicamente en torno a la página de backend que ofrece esa funcionalidad.
Dado que Vue y Razor pueden hacer muchas de las mismas cosas, mi objetivo para las páginas públicas es usar Razor para generar lo más cerca posible del html final y usar Vue para agregar reactividad a la página. Esto ofrece grandes beneficios de SEO para los rastreadores que indexan la página analizando el HTML devuelto.
Me doy cuenta de que mi uso de Vue es bastante diferente a seguir la ruta de un SPA y WebPack y el enfoque a menudo significa que no puedo usar componentes Vue de terceros sin volver a trabajar un poco el código. Pero el enfoque simplifica la arquitectura del software y ofrece una IU reactiva liviana.
Al usar este enfoque, Razor se puede aprovechar en gran medida para generar la representación inicial del HTML con algunas etiquetas que contienen vue attributes. Luego, una vez que la página se carga en el navegador, Vue se hace cargo y puede reconfigurar esa página de la forma deseada.
Obviamente, este enfoque no se ajustará a las necesidades de todos los desarrolladores o proyectos, pero para algunos casos de uso es una configuración bastante agradable.
Algunos detalles más para los interesados.
Como utilizo vue en todo el sitio, mi archivo _layout.aspx global es responsable de crear instancias de vue. Cualquier funcionalidad en todo el sitio implementada en vue se implementa en este nivel. Muchas páginas tienen una funcionalidad de vue específica de la página, esto se implementa como un mixin en esa página o un mixin en un archivo js cargado por esa página. Cuando la página _layout.aspx crea una instancia de Vue, lo hace con todos los mixins que he registrado en un mixin global array. (La página empujó su mezcla en esa mezcla global array)
No uso archivos .vue. Todos los componentes necesarios se implementan directamente en la página o, si necesitan ser utilizados por varias páginas, se implementan en una vista parcial como la que se muestra a continuación:
dlogViewComponent.cshtml:
@* dlog vue component template*@
@* Vue dlog component *@
En lo anterior, es el Vue.component (‘dlog’, … parte del js que instala el componente y lo pone a disposición de la página.
El código vue en la página _layout.cshtml se parece al código siguiente. Al crear una instancia de Vue en el _layout.cshtml que es utilizado por todo el sitio, Vue solo se instancia en un solo lugar en todo el sitio:
_layout.cshtml:
Lo que he proporcionado aquí pinta una imagen bastante clara de este enfoque no tradicional y sus beneficios. Sin embargo, como varias personas me preguntaron, también escribí una publicación de blog relacionada: ¡Usar VueJs con ASP.NET Razor puede ser genial!
Puedes hacerlo. A veces está obligado a hacerlo si, como nosotros, está migrando una base de código existente y no puede convertir todo a la vez. Y como dice Ron C, funciona bien.
Si está iniciando un nuevo proyecto, tiene el lujo de elegir. Razones para favorecer un SPA y no Razor serían …
-
Reactividad. Las aplicaciones de SPA generalmente se sienten (mucho) más reactivas. Las representaciones iniciales a menudo se sirven desde la caché, antes de que lleguen los datos. En la primera carga, todos los recursos llegan en un paquete, en una solicitud-respuesta. No hay, o mucho menos, encadenamiento de solicitudes.
-
Flujo de trabajo. Webpack, empaquetado y recargas en caliente son geniales. Obtiene compilaciones de producción, con minificación, compilación de funciones de renderización de Vue, eliminación de errores de estilo 404, errores de sintaxis js atrapados. El ciclo desde la introducción de un error hasta su descubrimiento se reduce considerablemente para muchos errores.
-
Universo SPA. Enrutamiento, Vuex, este es realmente el camino del futuro.
-
Pureza. Razor y Vue hacen cosas similares al final del día. Si los mezcla, puede tener dificultades para mantener la cabeza recta.
Ahora también puede lint las plantillas de VueJS dentro de las vistas de Razor:
https://www.npmjs.com/package/razor-vue-lint
Aquí tienes las reseñas y calificaciones
Ten en cuenta dar visibilidad a este tutorial si te ayudó.