Next.js: Usar con React Router 4

Creado en 5 abr. 2017  ·  122Comentarios  ·  Fuente: vercel/next.js

¿Es posible usar next.js con el nuevo enrutador react v4?

Comentario más útil

@timneutkens agregar la integración del enrutador react ayudaría a aumentar la adopción de nextjs y mejoraría el desarrollo. A los desarrolladores como yo les encantaría que esto suceda, por favor considere aumentar la prioridad.

Todos 122 comentarios

@Knaackee ¿

Luego tiene su propio enrutador, ¿por qué usar RR?

@sergiodxa Opciones de pesaje cuando

@oyeanuj 🤔 puede migrar gradualmente a Next, simplemente configure Next.js para manejar 1 ruta y use un proxy para tener tanto su aplicación actual como la de Next.js, luego mueva una segunda ruta de RR a Next.js, y eso forma en que puede mantener su aplicación actual durante la migración, eventualmente tendrá todo en Next.js

Al observar los ejemplos, parece que next tiene una única tabla de rutas como RRv2-3 y no admite "rutas anidadas" como RRv4. Estos son bonitos.

Intentaría usar RR o hay una gran advertencia que no conozco?

@igl ¿Has encontrado una solución para eso?

El nuevo paradigma react-router 4 de rutas anidadas es un cambio de juego y es algo imprescindible en nuestro proyecto actual. Me pregunto si alguien ha logrado que rr4 funcione con next.js.

MemoryRouter funciona, si no es como se esperaba ...
De lo contrario, los componentes dinámicos pueden ser solo del lado del cliente, donde HashRouter funciona bien ...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

También sigo el enfoque de react-router y todo el contenido renderizado por el servidor con next enrutador.

@malixsys @pegiadise, ¿ puede darnos más detalles sobre cómo usar el próximo enrutador y react-enrutador juntos?

Puede establecer una bandera en componentDidMount y renderizar condicionalmente <Router /> cuando la bandera es veraz. ( componentDidMount no se ejecuta en el servidor 😉)

De hecho, pronto incorporaremos React Router dentro de Next.js :)
- https://twitter.com/rauchg/status/948318111828099072

¿Sigue sucediendo esto? Puedo ver las notas de la versión para V6 canary y no se mencionan.

Finalmente. Definitivamente está en nuestras mentes. Tenemos otras prioridades en este momento (componente de diseño, desarrollo confiable y algunos otros problemas abiertos desde hace mucho tiempo).

Es una pena, puede que sea una prioridad baja para el equipo, pero básicamente es lo único que impide que personas como yo comiencen a usarlo. Leí tu tutorial hasta que llegué al punto en el que decía que las rutas deben configurarse dos veces y luego me rendí.

@timneutkens agregar la integración del enrutador react ayudaría a aumentar la adopción de nextjs y mejoraría el desarrollo. A los desarrolladores como yo les encantaría que esto suceda, por favor considere aumentar la prioridad.

Es una pena, puede que sea una prioridad baja para el equipo, pero básicamente es lo único que impide que personas como yo comiencen a usarlo.

Mismo.

¿Podemos al menos volver a abrir este problema para poder rastrearlo?

Voy a reabrir esto, pero tenga en cuenta que este es un proyecto de código abierto y no tenemos un caso muy sólido en este momento para zeit.co, ya que usamos Next.js para todo.

Es por eso que decía que es parte de los objetivos a más largo plazo y no se puede implementar de inmediato, pero estamos trabajando para lograrlo.

Las características que he estado introduciendo en Next 6 en realidad funcionan para el soporte de React Router.

Teníamos otras prioridades para Next 6, que están mejorando enormemente la confiabilidad y escalabilidad de Next.js, por ejemplo, resolución de página 100 veces más rápida, componente de la aplicación, hacer que la próxima exportación funcione en desarrollo, babel 7, etc.

Espero que esto amplíe mi comentario anterior.

Entonces el TLDR es:

  • Lo haremos, pero no de inmediato.
  • Next 6 tiene muchas mejoras en diferentes partes de Next.js

Para extender aún más el comentario de @timneutkens : definitivamente queremos RR, pero no tenemos ninguna limitación apremiante en el enrutador actual que lo haga una prioridad. Todos los casos de uso de enrutamiento que pueda imaginar se han implementado con éxito con la API Next.js actual

Hay dos razones por las que realmente queremos compatibilidad con

  • Simplifique nuestra propia base de código Next.js, no tenga que mantener nuestro propio enrutador, haga las cosas más pequeñas y modulares
  • Simplifique la ruta de migración de grandes aplicaciones que ya utilizan RR

Como tal, estoy de acuerdo en que deberíamos mantener este tema abierto.

Como contrapunto, no tener react-router significa que next funciona bien con relay-modern y fue una de las razones por las que cambiamos a next desde nuestra antigua aplicación react-router.

@merrywhether trabajé en una aplicación RRv4 con relay-modern el año pasado. ¿Le importaría ser más específico?
No recuerdo que tuviéramos problemas serios por ninguno de los dos.

@igl Esto es de acuerdo con la documentación de retransmisión: https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

El problema es que el enfoque de componentes de RRv4 no permite el determinismo durante el paso de precompilación, lo que puede dar lugar a cascadas de solicitudes en el cliente.

@rauchg Por interés, mi comprensión del enrutador de Next es que no es compatible con el concepto de enrutamiento anidado, por lo que puede mantener el marcado externo mientras navega dentro de una página. ¿Sabes si hay alguna forma de hacerlo posible con el enrutador actual?

@dbbk revisa nuestra aplicación de ejemplo de nextgram (https://github.com/now-examples/nextgram), hace exactamente eso

En los próximos 5, logramos un "marcado externo" al tener componentes de diseño de nivel superior que se extienden en todas nuestras páginas: el diseño base tiene navegación superior, luego algunos diseños secundarios que amplían la base para listas / detalles / etc., y luego Los componentes de nuestras páginas amplían estos sub-diseños con su propio contenido específico. En los próximos 6, también podría lograr un "marcado externo" básico usando _app.js , creo.

¿Se podrá configurar la próxima versión para elegir una solución de enrutamiento que no sea React Router?

Hola, solo necesito reaccionar enrutador para pasar accesorios a las páginas (usando <Route render ={} /> lugar de <Route component ={} /> ), ¿puedo hacerlo con Next?

Al observar los ejemplos, parece que next tiene una única tabla de rutas como RRv2-3 y no admite "rutas anidadas" como RRv4. Estos son bonitos.

Hola,

¿Significa esto que tengo que crear una sola página para una sola ruta?

Digamos si tengo 2 rutas sign up , log in . Tendría 1 página que comparte el mismo diseño, la única diferencia es el área de formularios. Es decir, solo necesito crear 1 archivo en la carpeta pages . Pero con las siguientes rutas tengo que crear 2 archivos en la carpeta pages . ¿Lo es?

Si es así, entonces el diseño se vuelve a montar con cada navegación, no solo en el área de formularios, ¿verdad?

@ 7c78 Una cosa que puede hacer es aprovechar _app.js para un diseño de página persistente para todas las páginas. La otra cosa que debe hacer es crear componentes de diseño compartidos que pueda reutilizar en varias páginas para lograr lo que está buscando:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

Además, puede hacer lo que hemos hecho recientemente y definir los componentes de diseño base que se extienden todos los componentes de su página:

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

Y luego simplemente extiende BaseAuth en sus páginas de inicio de sesión y registro y define formContent y formSubmit en cada una de ellas (estos son ejemplos de juguetes, ya que no conozco sus requisitos exactos).

@felicidad
Actualmente utilizo su enfoque, y los siguientes ejemplos también lo usan.

Pero mi preocupación es que necesito crear páginas separadas para formularios separados. Es decir, se reutiliza el diseño, pero no la página. Y el diseño se vuelve a montar con cada navegación.

Con RRv4, tenemos una sola página y los formularios se representan / vuelven a montar según las rutas (no la página completa). Las rutas son solo componentes.

¡Gracias por la rápida respuesta!

@ 7c78 Eso es cierto acerca de volver a montar, aunque creo que los nodos DOM se reutilizan cuando el vDOM se resuelve en el mismo estado.

No es algo que nos haya preocupado mucho porque tampoco podemos usar react-router con relay-modern, por lo que hemos tenido que usar este patrón independientemente.

@merrywhether No estoy seguro de vDOM porque el servidor devuelve un nuevo documento / html para cada ruta. Lo siento, ignora esta suposición, solo soy un novato.

Estoy de acuerdo en que tenemos que usar este patrón de todos modos. ¡Gracias!

Puede usar RR con next.js haciendo que toda su aplicación esté en las páginas / index.js, pero pierde algunas de las ventajas de la siguiente división de código lista para usar y tiene que configurarla usted mismo.

Me encantaría que se considerara Reach Router. Es muy similar a react-router y aporta algunos beneficios importantes:

  • Resuelve algunas inquietudes importantes relacionadas con la generación de enlaces y la gestión del enfoque (https://reach.tech/router/accessibility).
  • Pesa menos (al momento de escribir este artículo)

Reach Router también es genial 🥇

Las rutas dinámicas de estilo RR son una buena API, pero el enrutamiento estático (y analizable estáticamente) también trae muchos beneficios. Ninguno de los enfoques es un ganador absoluto.

@sorokinvj Eso solo se admite a través de un complemento (actualmente) ... https://github.com/fridays/next-routes

Los enlaces estáticos son tan básicos que ni siquiera admiten parámetros en los enlaces ...

Estoy usando un paquete de terceros next-routes por ahora https://github.com/fridays/next-routes para evitarlo

Enviado desde mi iPhone

El 24 de octubre de 2018, a las 23:01, Andy Ingram [email protected] escribió:

Las rutas dinámicas de estilo RR son una buena API, pero el enrutamiento estático (y analizable estáticamente) también trae muchos beneficios. Ninguno de los enfoques es un ganador absoluto.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

También estamos usando next-routes por el momento, pero creo que el próximo equipo está trabajando para agregar parámetros de ruta al enrutamiento de su sistema de archivos a través de nombres de archivos regex (inspirados en Sapper).

@merrywhether estoy usando next-routes también pero preferiría que esto sea parte del núcleo de Next.js.

Mencionaste

Creo que el próximo equipo está trabajando para agregar parámetros de ruta ...

Tengo curiosidad, ¿tienes alguna referencia para esto? ¿Quizás un problema abierto para los parámetros de ruta? No puedo encontrar uno ... Quizás el complemento resuelva la necesidad y esa será la solución recomendada en el futuro.

@curran La fuente fue un tweet de uno de los desarrolladores de sapper.js, diciendo que lo siguiente fue inspirarse en sapper.js e implementar regex-filename-routing en una versión futura. Por supuesto, siendo Twitter lo que es, no pude por mi vida encontrar el tweet original.

Este problema se planteó el 5 de abril de 2017 y ahora es el 27 de febrero de 2019. Casi 2 años y sin solución
¿Puede ser el momento de reemplazar el enrutador incorporado a medias con algo bueno?

Ay. Eso es bastante insultante para los desarrolladores de NextJS que dedican muchas horas a la solución de enrutamiento.

Extrañaba ReactRouter al principio. Ahora ni siquiera recuerdo que NextJS tenga un enrutador diferente hasta que alguien me lo recuerda. La API Link detallada es trivial de ajustar con proxies (dependiendo de su arquitectura de datos / API), por ejemplo. Compartiendo este alto secreto: 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}
<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

Creo que todos deberíamos pasar menos tiempo quejándonos de cosas secundarias 😉

@ ivan-kleshnin Nice agregué un contenedor similar

Según el comentario anterior, me gustaría señalar https://www.contributor-covenant.org/version/1/4/code-of-conduct

He ocultado dicho comentario.

No tengo ningún problema con next/router para la mayoría de los casos de uso.
Pero debería mejorar un poco en la parte universal routing .
En el caso de la implementación de Now 2, me encantaría tomar now.json y usarlo para enrutar en mi aplicación.

Si desea implementar RR4 en el proyecto nextJs, debe hacer 2 cosas:

  1. Evite NextJS SSR, al usar next/dynamic puede hacerlo.
  2. Usando HashRouter lugar de BrowserRouter -> si el usuario vuelve a cargar la página, el navegador puede cargar la página anterior (no la página 404)

Si desea implementar RR4 en el proyecto nextJs, debe hacer 2 cosas:

  1. Evite NextJS SSR, al usar next/dynamic puede hacerlo.
  2. Usando HashRouter lugar de BrowserRouter -> si el usuario vuelve a cargar la página, el navegador puede cargar la página anterior (no la página 404)

Gracias por esta respuesta, me ayudó mucho.

@ reach / router y react-router 5 se fusionan: https://reacttraining.com/blog/reach-react-router-future/

¿Cómo afecta esto a next.js?

@ alp82 Dado que Next.js todavía no usa React Router o Reach Router, no afectará a Next.js en absoluto.

Necesito la funcionalidad de cambiar rutas en nextjs para representar componentes de varias páginas en páginas de índice.
entonces, ¿cómo puedo implementar esto en nextjs ....... ???

Si desea implementar RR4 en el proyecto nextJs, debe hacer 2 cosas:

  1. Evite NextJS SSR, al usar next/dynamic puede hacerlo.
  2. Usando HashRouter lugar de BrowserRouter -> si el usuario vuelve a cargar la página, el navegador puede cargar la página anterior (no la página 404)

si desea volver a renderizar su página anterior sin lanzar el error 404, simplemente use esta ruta de obtención en su archivo de servidor express.

server.get ('tus parámetros', (req, res) => {
const actualPage = '/ your_page'
const queryParams = {id: req.params.id}
app.render (req, res, actualPage, queryParams)
})

Documenté un enfoque para usar next.js con react-router , proporcionando un archivo de punto de entrada único en lugar del enrutamiento basado en el sistema de archivos nativo y preservando completamente nativas de SSR .

Estaré feliz de recibir comentarios y mejorar lo que hice.

La documentación está disponible como:

¡Salud!

No recomendaría incluir react-router de esa manera, ya que termina con un solo punto de entrada, lo que significa compilaciones de desarrollo (tremendamente) más lentas, una mayor probabilidad de enviar demasiado código al lado del cliente y menos visibilidad de optimizaciones como la exportación automática de estática.

@timneutkens Tal vez me equivoque. Pero con la carga diferida, la configuración de enrutamiento es solo un archivo de configuración. No veo que afecte la escalabilidad o el rendimiento aquí. Me encantaría aprender más sobre esto.
El beneficio de react-router es que los desarrolladores tienen un control total sobre el código.

@timneutkens , no comenzaré una discusión aquí, pero le ruego que des-oculte mi comentario. Pasé tiempo para hacer que mi trabajo estuviera disponible y devolvérselo a la comunidad y no veo cómo silenciar a las personas podría ayudar al desarrollo de código abierto.

@timneutkens en cuanto a los puntos que mencionas, es una cuestión de compensaciones. El mío es un experimento para sondear cómo se podría usar Next.js con una configuración diferente.

Demasiado código en el lado del cliente

Cualquier paquete moderno puede dividir los activos del cliente en trozos y las rutas react-router son en realidad puntos de división muy convenientes.

Tiempos de construcción de desarrollo más altos

Es un precio a pagar por un gran proyecto, pero nada que no se pueda abordar con un ajuste fino adecuado del paquete web.

Sin exportaciones estáticas

Estoy de acuerdo en que las exportaciones estáticas son una capa de optimización importante. La mayoría de las páginas servidas por una aplicación Next.js promedio tienen que recuperar datos dinámicos de todos modos y no pueden beneficiarse de las exportaciones estáticas.

No hay falta de solución sobre esta preocupación. P.ej. todavía es posible declarar manualmente una lista de rutas para exportar estáticamente

La razón por la que oculté el comentario es que se trata de un problema de alto tráfico y no refleja nuestra recomendación para crear aplicaciones Next.js. Si alguien termina aquí buscando usar react-router, terminará usando ciegamente su ejemplo y sin investigar cómo configurar correctamente el enrutamiento usando Next.js.

Es un precio a pagar por un gran proyecto, pero nada que no se pueda abordar con un ajuste fino adecuado del paquete web.

No puede acelerar el arranque en tiempo de desarrollo según su enfoque, no hay un ajuste fino específico de la configuración del paquete web, ya que el paquete web simplemente compilará y observará cada ruta que importe, lo que ralentizará enormemente las ediciones en componentes comunes. De ahí por qué Next.js tiene entradas bajo demanda: https://nextjs.org/blog/next-8#improved -on-demand-entries

Además, hay una búsqueda previa (automática) de rutas, etc. Hay toneladas de detalles en los que podría entrar aquí, pero el tldr es que terminarás con una peor experiencia de desarrollador y aplicación.

No me importa ocultar el comentario si refleja correctamente que la única vez que desea usarlo es para migrar una aplicación que ya está usando react-router y luego pasar gradualmente a varias páginas.

Hola @timneutkens
¿Contarías algunas de las ventajas que aporta el análisis estático y que no son posibles con las soluciones de enrutamiento dinámico?

He leído todos los comentarios y aún no tengo claro si RR4 + se incluirá u opcional en la próxima iteración de next.js. ¿Es la hoja de ruta de un enrutador o algo similar?

@laurencefass parece que no hay ningún plan para admitir react-router (a partir de hoy).

Para mí, el sistema de enrutamiento de Next.js se está volviendo lo suficientemente maduro, por lo que probablemente no lo necesitemos (más) de todos modos :)

"Para mí, el sistema de enrutamiento de Next.js se está volviendo lo suficientemente maduro, por lo que probablemente ya no lo necesitemos :)"

Excepto para aquellos que buscan adoptar Next.js de forma incremental en una base de código existente. Creo que la discusión más útil probablemente no sea "enrutamiento Next.js vs enrutamiento react-enrutador". Creo que la discusión más útil es "¿cómo puedo migrar una aplicación enorme usando react-router a Next.js, de forma incremental?"

Sin embargo, el enrutador de Next no tiene la capacidad de anidar vistas de ruta, ¿verdad? Cada navegación a una ruta destruye el DOM y lo actualiza. Las vistas anidadas son un requisito bastante común.

@dbbk Escuché que el equipo de nextjs está trabajando en eso.

next js es bastante flexible con enrutadores. https://dev.to/toomuchdesign/next-js-react-router-2kl8

Estoy moviendo un sitio web de códigos JS y jQuery normales a React. A diferencia de los códigos anteriores, necesito evitar que la música se detenga al cambiar de página, así que usé React Router para eso.

Ahora, para fines de SEO, debido a que tengo un buen tráfico de la Búsqueda de Google, necesito mantener eso. Entonces preferiría SSR con Next.js para un mejor rendimiento.

Si Next.js puede representar una página en el lado del servidor y luego, una vez que la página se carga en el lado del cliente, Next.js permitiría la navegación bajo el control de React Router, de modo que si el usuario está escuchando música, el enlace de Next.js ganó ' ¿Tienes que salir de la página actual para detener la música?

¿Puede Next.js hacer solo enrutamiento del lado del cliente?

Si la integración de React Router puede resolver esto, entonces estoy dentro. Porque la reproducción continua de música es imprescindible para mí una vez que la aplicación llega al lado del cliente.

next js es bastante flexible con enrutadores. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , ese es un muy buen enfoque, lo leí antes. Y el artículo dice que el equipo de Next.js no lo recomienda, no sé por qué. Pero me parece bien

@KeitelDOG no necesitas react-router para eso, el enrutamiento de Next.js te traerá los mismos beneficios, además tu aplicación será más liviana gracias a la división automática de código (que no tendrías fácilmente con react-router)

_editar: Solo agregaré esto: quizás la única ventaja de react-router son las rutas anidadas fáciles en la misma función de vista, el enrutador Next.js debería resolver el 95% de sus casos de uso_

@martpie Gracias por la respuesta, eso es lo que vi ayer por la noche con el componente Link . Entonces Next.js es la mezcla de servidor y cliente que quería.

Y para un componente que controla de forma granular sus propias rutas anidadas de forma dinámica, me gusta mucho con React Router. Pero estoy bastante seguro de que puedo solucionarlo, porque no estoy cambiando un sitio web de React a Next.js, sino que estoy planificando y probando para cambiar un sitio web JS - jQuery a una aplicación de varias páginas de React sin perder mis ventajas de SEO en Google. Entonces creo que debería ir con Next.js

@timneutkens ¿ algún plan para admitir esto en Next.js 10?

@TrejGun gracias, eso definitivamente no está fuera de tema.

¿Tienes algún plan?
El next/router es genial, proporciona mucha ayuda. Pero necesitamos un enrutador más profesional para hacer frente a aplicaciones complejas. React-router es líder en enrutadores.
Quizás pueda referirse a after.js .

Sí, este sistema basado en páginas simplemente no es lo suficientemente sofisticado para manejar aplicaciones complejas basadas en datos que podrían beneficiarse de rutas anidadas.

React-router está a punto de lanzar la versión v6 , que será el mejor enrutador hasta la fecha. Estoy deseando que next.js respalden.

Un mejor enfoque es separar next.js y router , permitiendo a las personas elegir libremente su favorito router .

+1 para comentario anterior. next.js es increíble, la única razón por la que no lo estoy usando es la falta de flexibilidad en el enrutador. Admite React Router 6 en futuras versiones o haz que el router sea intercambiable.

Las personas realmente interesadas en React Router podrían estar interesadas en seguir el nuevo proyecto "Remix", es una alternativa de Next.js que usa React Router, de los mismos creadores:

Creo que el problema es que el marco está profundamente vinculado a ese enrutador debido a SSR, accesorios del lado del servidor, etc.

Next se construye teniendo en cuenta el rendimiento, y el react-router del lado del servidor tiene una implicación importante en el rendimiento, ya que debe recorrer el árbol DOM antes de saber qué intentará representar y, por lo tanto, qué datos necesitará. El propósito completo de getInitialProps es que no tenga que hacer un renderizado desechable de reaccionar antes de obtener datos, un error común que muchos marcos experimentan en el servidor (y en el cliente, donde se manifiesta como solicitar cascadas). Next podría potencialmente evitar esto haciendo que cada página de nivel superior declare _todos_ los diversos patrones de datos que pueden necesitar varios subcomponentes y se ramifique en la ruta de solicitud completa (o haga una sobrecarga única masiva), pero esto se volvería difícil de manejar rápidamente y en realidad, no sería tan diferente de declarar cada página individualmente.

Esta es la misma razón por la que Relay tampoco es compatible con react-router, y no se puede acusar a facebook.com de no ser un sitio web complejo.

La principal estrategia exitosa para trabajar con el enrutador Next es apoyarse en la componibilidad (que es la tendencia impulsora en el React moderno de todos modos), lo que le permite reutilizar componentes sin una duplicación importante y al mismo tiempo tener un SSR eficiente que puede recuperar todos sus datos. (a través de getInitialProps ) antes de hablar con el renderizador React.

Siento como si la penalización del desempeño de caminar sobre el árbol fuera exagerada. Hoy en día, muchas aplicaciones de producción están haciendo esto con, por ejemplo, Apollo y parece estar bien.

Además, también puede almacenar en caché CDN sus respuestas si realmente desea aliviar al servidor de hacer demasiado trabajo.

Claro, solo estoy señalando el razonamiento principal detrás de por qué react-router es (AFAICT) fundamentalmente incompatible con Next en su implementación actual. Muchos sitios realmente no necesitan rendimiento en absoluto, como lo demuestran las personas que usan felizmente los dynos gratuitos de Heroku con tiempos de inicio en frío lentos (y quiero enfatizar que no digo esto condescendientemente, ya que también hago esto para algunos sitios y puede ser el ajuste perfecto). Pero Next no sería popular entre algunas de las empresas más grandes que lo utilizan si fuera menos agresivo en cuanto al rendimiento, ya que a esas empresas les importaría que los tiempos de respuesta de sus servidores fueran considerablemente más lentos. Si no fuera una preocupación para algunos sitios, la gente no usaría (y esperaría ansiosamente las mejoras) el renderizador de transmisión de React para comenzar a responder incluso antes de que se haya completado un solo renderizado, y mucho menos dos.

Definitivamente puede almacenar en caché CDN sus respuestas, pero eso elimina muchas opciones de personalización / inicio de sesión (ya que es una compensación con qué tan bajo desea conducir su tasa de aciertos o diferir la representación parcial de la página al cliente). Si puede almacenar en caché CDN toda su aplicación, es mejor que use CRA y react-snapshot y evite los servidores por completo. No es necesariamente una cuestión de cuánto trabajo está haciendo su servidor, sino de cuánto tiempo lleva responder a una solicitud.

Y Apollo es un gran ejemplo de un marco que enfatiza la facilidad de uso sobre el rendimiento, en comparación con un marco más obstinado / orientado al rendimiento como Relay. Todo es un espectro.

Sí, supongo que es bastante justo. Pero tengo curiosidad por ver cómo resulta remix.run, tal vez se les ocurra un enfoque novedoso para que funcione con react-router . Sí, es cierto que las rutas anidadas no son obligatorias, pero seguramente debe estar de acuerdo en que es más intuitivo que partes de la interfaz de usuario interna cambien con la ruta, que tener páginas diferentes y envolver cada una de esas páginas con diseños diferentes.

A partir del próximo 9.3, hay getStaticPaths además de getServerSideProps para ayudar al marco a descubrir rutas para pre-renderizar cuando la ruta tiene parámetros de ruta. Quizás se podría tomar un enfoque similar con react-router.

@merryweather : "Next se

Pregunta ingenua: ¿Puede simplemente renderizar enlaces de nivel superior y obtener / prefetch / cache una vez que el código se ejecuta en el cliente? Si no sabe dónde navegará el cliente, ¿tiene sentido atravesar el árbol DOM en el servidor?

Escenario de trabajo ingenuo: cuando el cliente solicita una URL, simplemente renderice los enlaces de nivel superior y el contenido del enlace activo predeterminado y ajax / recupere todo lo demás a pedido (o precargue en segundo plano una vez que se cargue la página) ... todo lo demás incluye todo el nivel inferior rutas ... aclarar y repetir ...?

@laurencefass pero incluso los enlaces de nivel superior están en código y deben ser descubiertos, ¿verdad? ¿O quiere usar el enrutamiento del sistema de archivos junto con react-router para que los enlaces de nivel superior sean detectables?

@ avin-kavish No soy la mejor persona para responder los detalles sobre la implementación, pero el cliente solo necesita representar el contenido de la pantalla inicial: enlaces de nivel superior + contenido predeterminado. Cualquier otra cosa es redundante en la primera carga, creo. Entonces, ¿por qué recorrer el DOM en el servidor?

El problema principal con Next.js no es el enrutador, es el patrón de obtención de datos con getInitialProps , getServerProps o getStaticProps . Por qué ? Porque rompe el aislamiento de datos para el componente que lo necesita. Por ejemplo, si desea obtener datos para el menú, ¿de dónde los obtendrá? No lo sé. Los componentes principales como pages no deberían saber nada al respecto, ¿verdad?

El problema principal con Next.js no es el enrutador, es el patrón de obtención de datos con getInitialProps , getServerProps o getStaticProps . Por qué ? Porque rompe el aislamiento de datos para el componente que lo necesita. Por ejemplo, si desea obtener datos para el menú, ¿de dónde los obtendrá? No lo sé. Los componentes principales como pages no deberían saber nada al respecto, ¿verdad?

¿Podría explicarme por favor? ¿Y cuál es la solución alternativa?

@lishine Lo siento por un poco fuera de tema aquí, pero en la mayoría de los casos no veo que el enrutador sea el problema principal aquí. El enrutador Next.js es bueno, declarativo, la convención sobre la configuración es buena. Lo único que no puedo usar en Next.js son los métodos de obtención de datos como getInitialProps , ...
En mis aplicaciones, cada componente deberá declarar sus propios datos en el mismo lugar, en el mismo archivo, sea lo que sea graphql o rest.
El componente de páginas principales es solo para componer componentes secundarios y la obtención de datos no es su trabajo. El componente hijo debe obtener datos de sí mismo, no de sus padres.

Aquí está mi muestra de código que estoy usando para mi aplicación para mayor claridad:

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

Como puede ver, tiene un componente con sus propios datos. Puedes ponerlo donde quieras.

Por supuesto, puede usar el patrón Next.js sin ningún problema, pero en mi caso, prefiero el aislamiento de datos y componentes tanto como sea posible para facilitar el mantenimiento y la refactorización más adelante.

En mis aplicaciones, cada componente deberá declarar sus propios datos en el mismo lugar, en el mismo archivo, sea lo que sea graphql o rest.
El componente de páginas principales es solo para componer componentes secundarios y la obtención de datos no es su trabajo. El componente hijo debe obtener datos de sí mismo, no de sus padres.

Yo lo uso de la misma manera.
Entonces no está utilizando la búsqueda SSR ...
Entonces, ¿cómo la gente realmente busca SSR con Next.js?

@linshine tenemos que descargar lo que necesitemos en el nivel de la página superior.

@lishine Lo siento por un poco fuera de tema aquí, pero en la mayoría de los casos no veo que el enrutador sea el problema principal aquí. El enrutador Next.js es bueno, declarativo, la convención sobre la configuración es buena. Lo único que no puedo usar en Next.js son los métodos de obtención de datos como getInitialProps , ...
En mis aplicaciones, cada componente deberá declarar sus propios datos en el mismo lugar, en el mismo archivo, sea lo que sea graphql o rest.
El componente de páginas principales es solo para componer componentes secundarios y la obtención de datos no es su trabajo. El componente hijo debe obtener datos de sí mismo, no de sus padres.

Aquí está mi muestra de código que estoy usando para mi aplicación para mayor claridad:

...

Como puede ver, tiene un componente con sus propios datos. Puedes ponerlo donde quieras.

Por supuesto, puede usar el patrón Next.js sin ningún problema, pero en mi caso, prefiero el aislamiento de datos y componentes tanto como sea posible para facilitar el mantenimiento y la refactorización más adelante.

@ revskill10 ¿

Tenemos una aplicación Relay-Next y este patrón funciona perfectamente, con encapsulación de datos y composición reutilizable, y aprovechamos getInitialProps con facilidad.

@merrywhether Sin mencionar el much harder in REST , su enfoque tiene un problema de que no puede decidir qué fragments será SSG / SSR o será CSR.
En mi enfoque, es tan fácil como importar ese componente con { noSSR: true/false} .

Considero que el bloqueo a una biblioteca de enrutamiento específica de un proveedor que no comparte una implementación subyacente con ninguna biblioteca de enrutamiento importante es extremadamente preocupante.

Recientemente hice una revisión de Next.js para evaluar si debería usarse como base para el núcleo común compartido entre varias aplicaciones frontend que se están construyendo para nuestro cliente actual. Si bien Next.js tiene potencial; este enrutador es una de las principales razones por las que terminé rechazando Next.js y en su lugar manteniendo CRA como base para estas aplicaciones.

Entiendo la dificultad de usar la API de nivel superior basada en componentes de react-router / @reach/router como base para SSR. Pero esa no es una buena razón para que la implementación subyacente sea completamente personalizada. El SSG de Gatsby tiene las mismas preocupaciones que Next.js y una estructura de enrutamiento basada en archivos semi-similar; pero, según tengo entendido, Gatsby usa @reach/router bajo el capó para impulsar su implementación de enrutamiento en lugar de reinventar la rueda o exponer una API de enlace que es incongruente con la API de enlace utilizada por otras bibliotecas.

@dantman, ¿ puedo preguntar qué eligió para la alternativa de Next.js? Suponiendo que necesitara la representación del lado del servidor ... He estado probando After.js, tal vez pueda proporcionar algunas ideas / inspiración sobre cómo implementar en Next.js si no es compatible con zeit.

@dantman, ¿ puedo preguntar qué eligió para la alternativa de Next.js? Suponiendo que necesitara la representación del lado del servidor ... He estado probando After.js, tal vez pueda proporcionar algunas ideas / inspiración sobre cómo implementar en Next.js si no es compatible con zeit.

Lo siento, no tengo una respuesta útil para ti. SSR no era un requisito difícil, por lo que seguimos usando CRA, con el que se construyó el prototipo.

Pensé que Next.js era prometedor como marco universal, ya que recientemente obtuvo la capacidad de tener una combinación de páginas SSR / SSG / solo para clientes y podría ejecutarse como una aplicación isomórfica o como una aplicación estática / PWA. La personalización de WebPack fue tentadora porque CRA ha estado dificultando el uso del compilador globalizado. El servidor Next.js era neutral / positivo porque de todos modos necesitábamos un servidor API para un puente GraphQL / REST. Y la opción de SSR / SSG fue positiva, ya que estoy construyendo el núcleo en el que se basarán media docena de aplicaciones y no es imposible que pueda resultar útil en el futuro. Sin embargo, también tuve algunos problemas con la forma en que funciona el SSR de Next.js y estos aspectos positivos no valieron la pena el problema causado por el enrutador.

@dantman

Considero que el bloqueo a una biblioteca de enrutamiento específica de un proveedor que no comparte una implementación subyacente con ninguna biblioteca de enrutamiento importante es extremadamente preocupante.

Es bastante extraño calificar un componente de código abierto con una API que no ha cambiado en 3 años debido a su gran estabilidad y "ajuste de producto / mercado" como "bloqueo"

Next.js ha tenido éxito y sigue mostrando el crecimiento que hace gracias a su enrutador y no a pesar de él.

Como muchos me han visto comentar en Twitter, una vez nos entretuvimos seriamente en fusionarnos en algún enrutador (aunque estoy confundido sobre cuál es el estándar en su mente, Reach o React Router, y en qué versión principal). Pero el mundo nos llevó en otras direcciones interesantes. En realidad, ni siquiera sabíamos cuál era el objetivo de agregarlo, porque todos siguieron teniendo éxito con Next.js y creando productos maravillosos.

Cuando preguntaba a las personas por qué querían una API de enrutador diferente, la razón por la que surgía con mayor frecuencia es porque la gente estaba atascada y frustrada con las soluciones de marco de cosecha propia construidas en un enrutador, y no podían esperar para migrar a Next . No fue una razón arraigada en el diseño de productos.

Cuando digo que Next tuvo éxito debido a su enrutador, es porque eliminó dos problemas:
1️⃣ La idea de tener que elegir un router . Quitar esto es, en retrospectiva, una excelente decisión. En todo el tiempo que ha existido Next.js con su enrutador estable, el mundo del enrutador se ha dividido y ha lanzado todo tipo de cambios de API.

2️⃣ La curva de aprendizaje de un enrutador . Se han impartido muchos talleres y tutoriales sobre el enrutamiento, pero el enrutamiento del sistema de archivos Next.js requiere 2 segundos de explicación y le brinda la plataforma para construir cosas increíbles, y pasa directamente al desarrollo de productos.

Quiero enfatizar este último punto. Considere uno de los sitios web más nuevos y de más rápido crecimiento en el mundo, TikTok.com, construido sobre Next.js. La topología de enrutamiento completa de ese sitio web se puede explicar con esa curva de aprendizaje de dos segundos. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 es pages/[user]/video/[id].js y https://www.tiktok.com/trending es pages/trending.js

Muchas de las innovaciones recientes de Next.js que mencionas que te gustan, como híbrido estático / SSG / SSR, también están habilitadas por nuestro diseño de enrutador. De hecho, el enrutador también permitirá muchas otras optimizaciones similares que vendrán en el futuro para entregar menos JS a los clientes.

Sin embargo, también tuve algunos problemas con la forma en que funciona el SSR de Next.js y estos aspectos positivos no valieron la pena el problema causado por el enrutador.

Me encantaría escuchar sobre estos. El ejemplo anterior está impulsado por Next.js híbrido estático / SSR y vemos mucho éxito con él en todos los ámbitos.

Este es un hilo tan divertido. Next tiene razones concretas para evitar el enrutamiento en cascada (también conocido como react-router y amigos), ya que getInitialProps permite muchas optimizaciones de rendimiento, y el enfoque de Next está resultando ser bastante popular, especialmente porque algunas personas quieren específicamente esas optimizaciones. El rendimiento viene con compensaciones de diseño y, a veces, es posible que prefiera elegir el diseño sobre el rendimiento, pero eso no hace que la herramienta sea incorrecta, simplemente incorrecta para usted para un proyecto específico.

En última instancia, react-router no es la solución definitiva de enrutamiento. Tiene sus pros y sus contras, al igual que Next. FWIW, Facebook no usa react-router, y probablemente sepan un par de cosas sobre el uso de React. Así que está bien tener alternativas, y en realidad una de las mejores cosas del ecosistema JS: dejar que diferentes cosas compitan en el campo de las ideas y, en última instancia, todos avanzamos.

Ya que estoy cerrando el problema, quiero dejar en claro que siempre estamos abiertos a comentarios, solicitudes de funciones e informes de errores sobre las capacidades de enrutamiento.

Idealmente, estos deberían estar impulsados ​​por el producto ("Necesito hacer X pero no es posible" o "Y es posible pero no ergonómico"). Siempre estamos buscando mejoras que lo ayuden a crear sitios web y aplicaciones ajustados con excelentes experiencias de usuario 🤗

@rauchg ¿Puedes explicar la razón de tener dos accesorios, href y as en un enlace? ¿Por qué no puede inferir la página deseada basándose en el valor de as prop?

Por ejemplo, en express, si tengo una ruta como /blog/:slug , puedo enviar una solicitud http a /blog/hello-world y esperar que el enrutador se dirija a ella. No tengo que enviar tanto /blog/:slug como blog/hello-world al servidor.

@ avin-kavish esa es una gran pregunta. Se debe hacer una distinción importante entre lo que muestra la URL y la página que se va a cargar. De hecho, TikTok usa eso para representar ciertas cosas en modales, que cuando actualizas la página se convierten en otras páginas. Sin embargo, una gran área de mejora aquí es que quizás deberíamos hacer cumplir estáticamente que está haciendo referencia a una página válida que existe en el sistema de archivos. ¡Seguiremos creando una discusión sobre esto y etiquetarte!

Creo que ya existe un problema para eso https://github.com/zeit/next.js/issues/8207

En caso de que alguien haya visto este problema en busca de una función de "rutas anidadas" como el enrutador de reacción que permite navegar a nuevas páginas sin volver a renderizar todo como yo, en realidad hay un problema dedicado que puede ver y votar. Me acabo de enterar de eso: https://github.com/zeit/next.js/issues/8193

@rauchg

Para ser claro en esto, mi problema principal no es la falta de una API de componente de estilo RR / reach, estoy bien con una API basada en archivos / configuración con capacidad SSR. Aunque soy un poco optimista de que en el futuro Suspense podría hacer viables las API de SSR / enrutamiento alternativas. Mi problema principal es que el enrutador es completamente personalizado y cualquier preocupación común en la implementación se vuelve a implementar en lugar de compartir con cualquier parte de la comunidad React en general.

Encuentro que el enfoque de Gatsby es aceptable. Tienen una API de enrutamiento basada en archivos + configuraciones con capacidad SSG y exportan su propio componente Link mejorado; pero usan @reach/router para impulsar la implementación subyacente.

Considero que el bloqueo a una biblioteca de enrutamiento específica de un proveedor que no comparte una implementación subyacente con ninguna biblioteca de enrutamiento importante es extremadamente preocupante.

Es bastante extraño calificar un componente de código abierto con una API que no ha cambiado en 3 años debido a su gran estabilidad y "ajuste de producto / mercado" como "bloqueo"

El enrutador está intrínsecamente vinculado a Next.js. Adoptar Next.js por una razón significa estar vinculado al enrutador. Si adoptamos Next.js y luego descubrimos que next / router tiene una limitación que resulta paralizante para algo que estamos tratando de hacer, no hay absolutamente ninguna vía de escape razonable. "Lock-in" es un descriptor perfecto para eso.

El bloqueo por sí solo no sería un problema importante. El uso de Gatsby de @reach/router también sería bloqueado. Pero @reach/router se usa fuera de Gatsby. No tengo que confiar solo en la comunidad de Gatsby para mantener toda la pila del enrutador; Puedo confiar en que una comunidad más grande confía en él y que hay más partes interesadas involucradas (específicas de la pila de enrutamiento) para garantizar que se mantenga, se mantenga al día con los problemas de enrutamiento difíciles (por ejemplo, accesibilidad) y que dependa de una comunidad más amplia y variada que probablemente compartirá cualquier problema potencialmente paralizante que podamos encontrar en el futuro.

aunque estoy confundido en cuanto a cuál es el estándar en su mente, Reach o React Router, y en qué versión principal

En términos del estándar de facto de cómo debería verse <Link> . Tanto Reach como React Router (RR) comparten API muy similares. por ejemplo, <Link to='/about'>About</Link> es válido tanto en RR como en Reach (y, por supuesto, por extensión Gatsby). Lo que hace que el idiosincrásico <Link href='/about'><a>About</a></Link> Next.js sea mucho más discordante.

En términos de lo que creo que debería usar Next.js. No estoy atado a una biblioteca específica, si Next.js ya estuviera usando una, no sugeriría cambiar a otra. Mi principal preocupación es que la implementación de enrutamiento se comparta con una biblioteca con una comunidad más amplia fuera de Next.js.

En la práctica, aunque eso es relativamente discutible. Hasta ahora, no he visto ningún enrutador React además de RR y Reach con una gran base de usuarios. Y RR y Reach se convertirán en una biblioteca, por lo que el resultado final con el que empieces será el mismo.

Probé Next hace un tiempo, pero la falta de flexibilidad en el enrutador me llevó a descubrir una implementación de Razzle llamada After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com.

Como React Router es solo un paquete, ¿no podemos importarlo y limitar la representación solo al lado del cliente para que funcione como un SPA donde sea necesario y nos proporcione rutas de componentes anidadas? ¿No es el enrutador React solo un conjunto de componentes que se integrarán (potencialmente) en las páginas y se cargarán con el enrutador de páginas Next.js como cualquier otro componente?

Leí en hilos anteriores que zeit planea integrar RR. ¿Sigue siendo cierto hoy?

¿Por qué no permitimos rutas anidadas en el enrutador next.js como último recurso y dejamos en claro que estas áreas no se renderizarán previamente? Como mínimo, nos ahorrará el esfuerzo de tener que evitar escribir las condiciones if que tenemos que escribir inevitablemente cuando queremos que un sub-recurso de la página cambie en función de la ruta.

Estoy agregando mi voto sobre este tema.

Otro profesional, no mencionado, es que RR es más comprobable (AFAIK, no hay una API oficial de nextjs para pruebas de enrutadores), tiene MemoryRouter para envolver pruebas e historias.

Next.js tiene muchas características buenas (WebPack automático, archivos estáticos y TypeScript como CRA, pero para más que solo PWA; rutas API; soporte sin servidor, Fast Refresh e incluso soporte experimental de Expo para aplicaciones web + nativas) y un núcleo para SSR y SSG incluso si la API no es excelente. Pero mientras que el sistema de enrutamiento incorporado y SSR / SSG funcionan para algunos; para otros, dificultan el desarrollo porque los límites de ambas API ofrecen compensaciones incorrectas para dicho proyecto.

¿Qué tal un compromiso? Next.js ya tiene complementos. En lugar de reemplazar el enrutador internamente, ¿qué pasaría si separamos el enrutador y la API SSR (es decir, el getStaticProps / getServerSideProps en los archivos de ruta) del núcleo de Next.js. Por ejemplo, podríamos poner las partes fundamentales muy fundamentales en @next/core y mover el enrutador obstinado actual y las API de get*Props a @next/router . Por simplicidad y compatibilidad con versiones anteriores, next podría ser un marco que reexporta @next/core y viene preconfigurado con el enrutador preferido de Vercel. Pero entonces sería posible que la comunidad desarrollara enrutadores y API SSR / SSG con diferentes compensaciones que se adapten mejor a proyectos que, de otro modo, se quedarían estancados tirando las partes buenas de Next.js con el agua del baño.

Algunas ideas sobre lo que el núcleo de Next.js requeriría que el complemento del enrutador proporcione:

  • Dada una solicitud {url, cuerpo, etc.}, el núcleo esperaría que el complemento del enrutador presente esta solicitud en un documento (cadena o transmisión) o arroje una respuesta (es decir, 404 o redireccionamiento).
  • Al exportar, el núcleo esperaría que el complemento del enrutador proporcione una lista de páginas que deben renderizarse.

@next/router probablemente implementaría los mismos patrones a través de la api haciendo cosas como:

  • Ante una solicitud, identificando el archivo de ruta responsable y renderizándolo con normalidad
  • En el cliente que hace algo similar a lo que hace actualmente para saber cuándo llamar a la API SSR y representar la ruta que necesita (posiblemente moviendo la API SSR basada en API a una ruta API de aspecto normal)
  • Al exportar usando el árbol de archivos de páginas y getStaticPaths para proporcionar la lista de páginas estáticas

Probablemente podría verme experimentando con un complemento de enrutador usando React Router v6 con @apollo/react-ssr y Suspense con react-ssr-prepass o react@experimental . Que renuncia a las rutas solo SSR para rutas SSR isomórficas e implementa SSR / SSG sin una API de estilo get*Props restrictiva.

Me di cuenta de que el enrutamiento anidado + SSG se puede lograr sin romper la API actual. Entonces tenemos getStaticPaths en este momento, podemos usar eso para indicar rutas anidadas para prerrepresentar. Por ejemplo,

Dada una ruta /foo/[...slug] ,

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

se puede renderizar previamente con,

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

Con la forma en que está en este momento, next.js es como un marco del lado del servidor con la conveniencia de crear páginas en reacción. No se siente tan poderoso como react-router . El enrutamiento basado en directorios puede tener su lugar en la creación de sitios orientados al consumidor como tiktok, como se mencionó anteriormente, pero para los portales de aplicaciones complejos basados ​​en datos, el enrutamiento anidado sigue siendo el rey. Es por eso que se crearon aplicaciones de una sola página en primer lugar, permite cambiar partes de la interfaz de usuario sin tener que reemplazar la página completa. Esto se puede aprovechar para modelar las relaciones recurso-sub-recurso de manera bastante conveniente. Tal como está, puedo usar next.js si tuviera que construir las páginas públicas de un sitio para consumidores como un sitio de comercio electrónico, pero cuando necesite construir las áreas privadas como portales de administración, compradores y vendedores cambie a CRA.

@ avin-kavish, el problema principal no es hacer que funcione, sino optimizarlo: cada página en Next.js tiene su propio paquete predeterminado y está optimizada para la velocidad.

Si comienza a agregar una gran cantidad de contenido / subcontenido en una sola página como lo hizo, podría terminar con un paquete bastante grande al final (lo cual no es "terrible" per se, pero debe tener en cuenta compensaciones). Es posible que pueda hacer una optimización manual con next/dynamic pensamiento :)

@rauchg, la única dimensión no es si el próximo enrutador es bueno o malo. Otra cosa muy importante es la migración hacia y desde next.js y el soporte de la comunidad, y https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 lo expresa bien. Next.js es una buena solución para abstraer gran parte del modelo estándar que necesita una aplicación SSR de alta calidad y, como tal, es un objetivo de migración muy atractivo para muchas aplicaciones web. El problema en este momento es que necesitaría una reescritura completa del enrutamiento tanto para migrar a next.js como fuera de él si surge la necesidad.

El enrutamiento enchufable sugerido por @dantman anteriormente resolvería este problema de una manera muy elegante y no requeriría que nadie venda sus principios 😉

El problema con react-router (y cualquier solución de enrutamiento anidado) es que dificulta mucho el análisis estático porque las rutas de código relevantes para cualquier URL específica no están disponibles sin ejecutar (o simular) el código en sí. Lo siguiente es más que un marco de "poner la interfaz de usuario en una página web", razón por la cual, por ejemplo, trabajaron con el equipo de Chrome en la creación de estrategias de agrupación más optimizadas.

Los usuarios de react-router están acostumbrados a usar react-loadable directamente, ya que delega esa responsabilidad por completo a los usuarios finales, pero Next intenta abstraer y automatizar esto, lo cual no es fácil. El enfoque de enrutador enchufable propuesto probablemente tendría que involucrar complementos de enrutador que proporcionen información extensa sobre el tiempo de compilación al marco para lograr el mismo tipo de salida, ya que cada enrutador debería saber cómo generar dicha información en función de sus propios patrones.

Puramente especulación, pero imagino que muchas cosas están en el limbo mientras React termina Suspense, ya que hacer que un patrón de primera clase en la biblioteca afectará en gran medida a todas las bibliotecas de enrutadores y también dará una base concreta sobre la cual construir asíncrono / cargable patrones de paquete.

Breve historia / un buen resumen a continuación: No existe una "solución única para todos". Todo tiene compensaciones. Cada "ventaja" de la forma en que Next.js hace las cosas actualmente viene con una desventaja. Qué ventajas / desventajas son las más importantes es algo que es diferente para cada proyecto. Por lo tanto, la recomendación para una arquitectura enrutador / ssg / ssr conectable. Los diferentes proyectos necesitan cosas diferentes y en este momento Next.js solo funciona para los proyectos cuya prioridad en las compensaciones se alinea con la forma en que las cosas están codificadas en Next.js.

El problema con react-router (y cualquier solución de enrutamiento anidado) es que dificulta mucho el análisis estático porque las rutas de código relevantes para cualquier URL específica no están disponibles sin ejecutar (o simular) el código en sí.

Honestamente, eso solo importa si está usando SSG y tiene un montón de rutas no dinámicas. Si todas sus rutas son SSG o solo para clientes, eso no es útil. Y si la mayoría de sus rutas son dinámicas, entonces debe declararlas explícitamente usando getStaticPaths todos modos. Lo que sería la misma cantidad de trabajo que definir explícitamente las rutas en un complemento hipotético de Next.js que solo usa un enrutador de reacción sin procesar sin modificaciones y le pide que defina explícitamente rutas estáticas.

Seguro que es una ventaja, y algunos equipos la querrán. Sin embargo, ese es solo un subgrupo de usuarios potenciales de Next.js. Hay otros grupos que pueden querer algunas de las ventajas que ofrece RR u otra biblioteca de enrutamiento y la necesidad de declarar explícitamente las rutas estáticas es una compensación aceptable o un problema. Por ejemplo, mis últimos proyectos han sido el tipo de aplicaciones B2B / B2C en las que el 100% de las cosas están detrás de una página de inicio de sesión y no tiene sentido renderizar estáticamente nada. Next.js tiene algunas ventajas sobre CRA que habrían hecho que Next.js fuera preferible; Pero cosas como el enrutador eran grandes señales de alerta y seguimos usando CRA. Esos proyectos habrían sido muy adecuados para un Next.js con un enrutador de reacción sin formato.

Esto también supone que todos los que no quieren next/router quieren usar la forma JSX de react-router. Ese no es el único tipo de alternativa next/router .

Otro tipo de enrutador sería el estilo Gatsby.js. Donde un proyecto todavía usa una estructura de páginas basada en un sistema de archivos, pero las partes internas se implementan con otra biblioteca de enrutamiento como react-router (Gatsby usa @reach/router internamente). Este tipo de complemento de enrutador le brindaría las mismas ventajas de análisis estático. Pero también le brindaría todas las ventajas que el enrutador alternativo no haya relacionado con el enrutamiento anidado. Por ejemplo, adaptarse a las posibles preferencias de la API de ruta, mejor manejo de la accesibilidad, mejor integración en el ecosistema alrededor de ese enrutador.

Y, por supuesto, incluso dentro del ecosistema react-router, el formulario JSX no es la única forma de utilizar react-router. También hay react-router-config . Que es fácil de hacer análisis estático y también admite enrutamiento anidado.

Los usuarios de react-router están acostumbrados a usar react-loadable directamente, ya que delega esa responsabilidad por completo a los usuarios finales, pero Next intenta abstraer y automatizar esto, lo cual no es fácil.

Y algunos de nosotros estamos bien manejando la división de código por nosotros mismos. El enrutamiento anidado puede ser más importante para un proyecto que la división automática de código. Se trata de qué compensaciones se adaptan mejor a un proyecto.

Esto es más una nota al margen, pero en realidad tengo curiosidad sobre el potencial de un complemento de babel / webpack que haría esto automáticamente para las rutas.

También react-loadable es una biblioteca efectivamente extinta (2 años desde la publicación, no se aceptan informes de errores). Personalmente, preferiría dividir el código manualmente con @loadable/components que usar algo automático integrado en Next.js basado en una bifurcación interna de react-loadable.

El enfoque de enrutador enchufable propuesto probablemente tendría que involucrar complementos de enrutador que proporcionen información extensa sobre el tiempo de compilación al marco para lograr el mismo tipo de salida, ya que cada enrutador debería saber cómo generar dicha información en función de sus propios patrones.

Sip. Por lo general, así es como funcionaría un sistema de complementos. Honestamente, el hecho de que el complemento pueda proporcionar este tipo de información es una ventaja, no un problema. Tener esto en un complemento significa que si la forma en que Next.js recopila esta información no es adecuada para algunos tipos de necesidades de proyectos, se puede reemplazar por una que se ajuste a las necesidades de esos proyectos. Pero sin necesidad de bifurcar y reescribir todo Next.js para hacerlo.

Puramente especulación, pero imagino que muchas cosas están en el limbo mientras React termina Suspense, ya que hacer que un patrón de primera clase en la biblioteca afectará en gran medida a todas las bibliotecas de enrutadores y también dará una base concreta sobre la cual construir asíncrono / cargable patrones de paquete.

Esto en sí mismo podría ser un buen argumento para trabajar en un sistema de enrutador conectable. En este momento, debido a que todas las cosas de enrutamiento y SSR están codificadas en Next.js, no es posible realizar fácilmente la experimentación en ningún tipo de sistema de enrutamiento futuro dentro de Next.js. ¿Cómo afecta Suspense el enrutamiento de Next.js y otras bibliotecas de enrutamiento? No es algo con lo que pueda experimentar (al menos en lo que respecta al SSR y la agrupación de Next.js) sin bifurcar y reescribir trozos de Next.js.

Los complementos de enrutador serían un gran lugar para hacer este tipo de experimentación. Siempre que la API del complemento sea de nivel suficientemente bajo, sería posible bifurcar solo el complemento next/router e intentar escribir una versión basada en react @ experimental + Suspense de ese enrutador. Y debido a que este es un complemento (no una bifurcación de todos los de Next.js), sería fácil optar por el experimento y probar el nuevo enrutador basado en Suspense. Esto es importante ahora y no más tarde porque este tipo de experimentación es la razón por la que existe

@dantman No estoy en desacuerdo con nada de lo que has dicho. Todo se trata de compensaciones. La mayor compensación es en qué dedica su tiempo el equipo de Next. Hasta ahora, el SSR de alto rendimiento y baja configuración parece haber sido su enfoque principal. Entiendo que esto no es necesariamente relevante para todos los usuarios, pero es el ángulo que Next usó inicialmente para destacar (por eso los elegimos en el trabajo). Recientemente han investigado más en SSG, aparentemente debido a la popularidad de Gatsby y Jamstack, pero siguen siendo mejores para SSR imo.

Honestamente, eso solo importa si está usando SSG y tiene un montón de rutas no dinámicas

No estoy seguro de lo que quiere decir con esto, ya que SSG vs SSR realmente no importa para tratar de entregar la carga útil JS más pequeña posible para la primera página (JS de "ruta crítica"), ni tampoco las rutas dinámicas. Minimizar los activos de ruta crítica _es_ generalmente bastante importante para las aplicaciones SSR (por lo tanto, todo el esfuerzo), por lo que se agradece. Y, honestamente, si todo lo que está haciendo son aplicaciones solo para CSR con paredes de inicio de sesión, Next _ sí_ tiene muchas desventajas en comparación con CRA (SSR nunca será tan conveniente como CSR). Parece que está descontando aquellas aplicaciones que en realidad están haciendo SSR en tiempo de ejecución (con manejo del lado del servidor de inicio de sesión / personalización) específicamente para ganancias de rendimiento. No todo encaja en la dicotomía SSG vs CSR.

algunos de nosotros estamos bien manejando la división de código nosotros mismos

Algunos de nosotros también somos bastante capaces de manejar webpack, react-dom / server, etc. Hasta ahora, el objetivo de Next parece ser hacer que la expulsión sea cada vez más rara como CRA. Y tiene razón, debería haber dicho reaccionar-cargable-igual, porque hay muchas soluciones en ese espacio, y solo se están volviendo más exóticas con los patrones emergentes de datos más código de bibliotecas como Relay.

En última instancia, no estoy en desacuerdo con que un sistema de enrutador enchufable pueda ser bueno. Solo estaba señalando que sería mucho trabajo para el equipo de Next eliminar las cosas que son principios centrales del marco (como la lógica de división de paquetes) y extraerlas en una arquitectura conectable. Y mi especulación fue resaltar el hecho de que no querría comenzar a diseñar un cambio fundamental en mi biblioteca que podría ser fácilmente alterado por los próximos cambios en mi dependencia principal. Ciertamente estoy de acuerdo en que algunos aspectos del diseño de Next _son_ limitantes, pero en su mayor parte esos límites tienen sentido dadas sus limitaciones de diseño hasta ahora.

Honestamente, eso solo importa si está usando SSG y tiene un montón de rutas no dinámicas

No estoy seguro de lo que quiere decir con esto, ya que SSG vs SSR realmente no importa para tratar de entregar la carga útil JS más pequeña posible para la primera página (JS de "ruta crítica"), ni tampoco las rutas dinámicas.

Probablemente estemos pensando en diferentes razones por las que es necesaria la capacidad de analizar estáticamente qué rutas existen. Suponiendo que ambos estamos hablando de "análisis estático" como "la capacidad de identificar la lista de rutas (por ejemplo, ['/about', '/', '/profile'] ) en el momento de la construcción simplemente leyendo el código".

¿Parece que estás hablando de algún tipo de optimización de paquete JS? Sobre el cual no he encontrado ninguna información en la documentación, no sé exactamente en qué tipo de optimización basada en el análisis de ruta estática estás pensando.

Mi pensamiento era que este análisis estático de rutas era principalmente útil para SSG. es decir, porque el archivo pages/about.js existe cuando construyes tu sitio Next.js sabe que existe una ruta /about y necesita pre-renderizar el html para esta ruta, aunque nunca lo dijiste explícitamente hay una ruta /about para pre-renderizar.

SSR no necesita html precompilado, ya que solo lo hace cuando entra una solicitud (en ese momento ejecuta el código y tiene una ruta para representar). Las páginas renderizadas por el cliente no tienen HTML renderizado previamente en absoluto. Y si su página SSG es dinámica, debe declarar todas las rutas de todos modos. De ahí mis pensamientos.

Y, honestamente, si todo lo que está haciendo son aplicaciones solo para CSR con paredes de inicio de sesión, Next _ sí_ tiene muchas desventajas en comparación con CRA (SSR nunca será tan conveniente como CSR).

¿En qué desventajas estás pensando en Next.js con respecto a las aplicaciones de RSE? Aparte de los problemas del enrutador antes mencionados.

Según tengo entendido, Next.js admite la gama completa de rutas SSR / SSG / CSR. Por lo tanto, supuestamente sigue siendo adecuado para escribir aplicaciones solo CSR con paredes de inicio de sesión.

Personalmente, mi perspectiva es definitivamente de alguien que escribe muchas aplicaciones en gran parte de RSE, con necesidades ocasionales de SSR y SSG, que desea tener un solo conjunto de herramientas sólido para todos mis proyectos, sin importar qué combinación de SSR / SSG / CSR necesiten.

Desde mi experiencia, CRA tiene una gran cantidad de desventajas incluso dentro de las aplicaciones solo de CSR que podrían hacer que las páginas de CSR de Next.js sean ventajosas. La personalización de la configuración de WebPack sin expulsar es muy importante. Esto me causó mucho dolor cuando no podía simplemente usar el complemento WebPack del compilador globalizado cuando estaba agregando i18n a una aplicación. La posibilidad de optar por SSR / SSG para páginas específicas incluso si la mayoría de las páginas son CSR también es una ventaja (por ejemplo, el 99,9% de sus páginas son CSR y están detrás de una página de inicio de sesión; pero tiene una página de destino y tal vez términos / contacto páginas en las que desea SSG o SSR). No puedo hacer ninguna de esas cosas razonablemente con cosas como CRA.

algunos de nosotros estamos bien manejando la división de código nosotros mismos

Algunos de nosotros también somos bastante capaces de manejar webpack, react-dom / server, etc. El objetivo de Next hasta ahora parece ser hacer que la expulsión sea cada vez más rara como CRA

Honestamente, hacer manualmente la división de código basada en rutas (asegurándose de modificar uno para usar los componentes de su ruta a través de React.lazy o una biblioteca alternativa en lugar de una importación directa) está muy lejos de administrar manualmente una configuración o escritura de WebPack personalizada sus propios controladores SSR con react-dom/server .

Es completamente razonable no querer escribir manualmente una configuración de WebPack completa o un servidor SSR personalizado (es decir, querer usar un marco ampliamente utilizado como Next.js), pero aún así estar bien con el uso de react-router y hacer manualmente el código basado en la ruta terrible. Especialmente si optar por la división automática de código base de ruta significa perder la biblioteca de enrutadores ampliamente utilizada que está usando y usar un enrutador al que le faltan una serie de características que puede necesitar con una API muy diferente a cualquiera de los enrutadores en uso más amplio.

Siempre aterrizo en este problema cuando busco una forma de integrar react-router con NextJS que no requiere crear un servidor personalizado, así que decidí intentarlo yo mismo.

Con react-router v6 (beta), cree un _app :

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

Por qué

No es fácil administrar _optional catch all route_ en NextJS (por ejemplo: /foo/[[...bar]].js ), así que estoy explorando una forma de poder usar react-router para este tipo de páginas. Tal vez otros tengan diferentes razones, pero esa es mi principal preocupación y react-router proporciona una buena API, especialmente en v6, que actualmente está en beta.

Cómo funciona

Simplemente crea un MemoryRouter lugar de un BrowserRouter para que no arruinemos el historial del navegador al tener el enrutador NextJS y el enrutador NextJS. Escucha los cambios del historial de memoria para PUSH y REPLACE para que pueda usar react-router ganchos o Link para navegar, pero debajo del capó, sería llamar a los métodos de enrutador NextJS .push y .replace .

Es necesario llamar a los métodos de enrutador NextJS, de lo contrario, los cambios de ruta no activarán los métodos NextJS get*Props . En otras palabras, funcionaría de manera similar a la opción shallow usando NextJS Link . La desventaja de usar react-router Link es que no hay prefetch . Sin embargo, aún puede usar NextJS Link lugar y react-router aún puede reaccionar a los cambios de ruta.

Lo bueno de esto es que ahora puede aprovechar las rutas NextJS dynamic y react-router y hacer cosas como:

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

De todos modos, espero que esto ayude a alguien. No he usado esto en producción y este código es de un patio de recreo local que tengo, así que probablemente hay cosas que podrían mejorarse, pero es un comienzo.

Usando React Router con Next.js 9.5+

Si está utilizando Next.js 9.5 o posterior, la forma correcta de hacerlo es con Rewrites . _¡No utilice un servidor personalizado_! Hay un tutorial detallado sobre cómo hacer esto aquí: https://colinhacks.com/essays/building-a-spa-with-nextjs

La idea básica:

  1. Cree una aplicación personalizada ( /pages/_app.tsx )

  2. Devuelve null si typeof window === "undefined" . ¡Esto es necesario para evitar que el enrutador de reacción arroje errores durante el paso SSR!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

El atributo suppressHydrationWarning es para evitar advertencias que React lanza cuando el contenido renderizado por el servidor no está de acuerdo con el contenido renderizado por el cliente.

  1. Reescribe todas las rutas a la página de inicio
// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

¡Entonces puedes usar React Router como de costumbre! Hay mucho más contexto / explicación en el tutorial vinculado, pero esto lo ayudará a comenzar. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks Una buena solución puede confirmar que funciona. Algo en lo que pensar quizás sea en mover la aplicación a su propia página como app.js o routes.js o algo así. Luego, teniendo las reescrituras en

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

Solo algo en lo que pensar, tu solución es la mejor que encontré.

¿Fue útil esta página
0 / 5 - 0 calificaciones