@baldurh Esto es muy poco común, cuando se usan plataformas como Now, solo se implementa la carpeta donde se encuentra la aplicación Next.js, es mejor así porque de lo contrario primero necesitaría conocer todos los módulos externos. 2 mejores alternativas son:

• Mueva todo a una sola aplicación Next.js
• Utilice lerna o paquetes privados de npm o similares

@lfades gracias por la respuesta. Ninguna de esas opciones está disponible para nosotros y no estamos implementando en Now ni nada similar. Inicialmente usamos espacios de trabajo de hilo, pero luego integramos bazel y no juega bien con la naturaleza de enlace simbólico de los espacios de trabajo de hilo. Los paquetes Npm significan que no podemos desarrollar los módulos compartidos tan rápido como queremos. Es demasiada sobrecarga.

@baldurh Acabo de encontrar esto con next-i18next ya que tenemos aplicaciones NextJs anidadas como ejemplos. ¿Encontraste una solución?

@isaachinman No lo hemos hecho. No hemos logrado actualizar a 9.x todavía por otras razones, así que no lo he estado investigando. ¿Alguien tiene una idea de dónde podría estar el código que afecta esto? Me encantaría comprender mejor el problema.

No he tenido tiempo de profundizar en esto todavía, pero si alguien necesita una reproducción: clone next-i18next , cd en examples/simple y actualice la versión de NextJs a> = 9.0.6.

Actualmente está en 9.0.3, por lo que técnicamente es un cambio importante en un parche.

Tuve un error similar recientemente y tuve que degradar a 9.0.5 (y React 16.8.x). En cierto modo reduje el problema que vi al uso de MDX de Next, pero no tengo detalles concretos más allá de eso.

He investigado el mismo problema con un proyecto bastante grande basado en Next & next-i18next.

Vi que este error puede deberse a 3 razones:

1. Versiones reaccionar y react-dom desalineadas: no se aplican a mi aplicación
2. 2 versiones de react-dom importadas, no aplicadas a mi aplicación
3. Uso inadecuado de los ganchos de React: no uso ganchos, pero algunas bibliotecas sí, y parece que funciona para todos los demás.

Lo extraño es que ocurre solo en la construcción de producción.

@timneutkens @Timer lamento haberte etiquetado en esto, pero me encantaría

Parece que tienes un alias react pero no react-dom . ¿Puedes probar eso?

@Timer Gracias. Lo intenté pero no tuvo ningún efecto

Pude resolver esto justo ahora en la reproducción moviendo las dependencias react y react-dom un nivel hacia arriba. Solo presioné los cambios si alguien quiere probarlo. No lo he probado en nuestro proyecto actual, pero espero que funcione para nosotros. ¿Quizás esto podría resolver el problema para @isaachinman , @jaredcwhite y @felixmosh también?

@Timer Tengo este trabajo en nuestro proyecto, sino también tenía que asegurarse de que yo no tenía otras dependencias, que instalan react en nuestros proyectos node_modules carpeta. En nuestro caso estaba relacionado con el libro de cuentos ( yarn why react ayudó mucho 😄). De todos modos, estábamos planeando trasladar el libro de cuentos a un proyecto separado, así que creo que esta solución funcionará en nuestro caso.

Ah, sí. Los paquetes node_module publicados incorrectamente causarán esto (con dependencias en react(-dom|) lugar de dependencia de pares).

Pude resolver esto justo ahora en la reproducción moviendo las dependencias react y react-dom un nivel hacia arriba. Solo presioné los cambios si alguien quiere probarlo. No lo he probado en nuestro proyecto actual, pero espero que funcione para nosotros. ¿Quizás esto podría resolver el problema para @isaachinman , @jaredcwhite y @felixmosh también?

¿Puede darnos detalles sobre los cambios que ha realizado en este repositorio?

Ejecuto npm ls react o npm ls react-dom Solo tengo mi próxima aplicación en la lista.

@felixmosh Lo siento, aparentemente el empujón me falló ayer. Ahora los cambios definitivamente están ahí 😅 Moví react y react-dom de la carpeta app a la carpeta raíz, así que ahora debes hacer yarn/npm install tanto en app carpeta y la carpeta raíz antes de ejecutar app . Espero que esté bastante claro.

Tendremos que hacer algunos cambios en nuestro sistema de compilación para que esto funcione en producción, por lo que esta solución sigue siendo un poco complicada para nosotros 😝

Gracias por la explicación, esperaré a que Next team lo resuelva, suena un poco raro poner react deps en la raíz de mi mono-repo ...

@felixmosh Sí, estoy de acuerdo contigo. Sin embargo, si usa algo como espacios de trabajo de hilo, eso es exactamente lo que hará esa herramienta. Si tiene la misma dependencia en dos o más proyectos, elevará las dependencias a la raíz. Es bueno porque asegura que tenga la misma versión de las dependencias en todos sus proyectos. Pero si no tiene una herramienta como esa, tendrá que administrarla usted mismo, lo cual es un poco incómodo. Estoy de acuerdo en que la mejor solución sería que el equipo de Next.js eche un vistazo y resuelva esto por todos nosotros 😇🙏🏻

Encontrarse con el mismo problema, subir react y react-dom un nivel y ejecutar el servidor desde la raíz es la única solución que funciona actualmente en 9.1.5. Vinculando https://github.com/facebook/react/issues/13991 y https://github.com/facebook/react/issues/15315#issuecomment -479802153 como referencia, ya que encontré esos enlaces antes de este número.

Hola, ¿alguna actualización sobre este tema? Tenemos un monorepo y nos encontramos con este problema exacto.

Resuelva el mismo problema.
v9.0.5 funciona muy bien con ganchos para componentes importados fuera de rootFolder.

A partir de 9.0.6 hasta 9.1.6-canary.5 tiene los mismos problemas.

El problema ocurre solo en el lado del servidor. Si SSR está deshabilitado (por ejemplo, cargar un componente externo a través de dinámica ) entonces todo funciona como se esperaba para las versiones> = 9.0.6.

@nodkz es un problema con la resolución del paquete react, por lo tanto, solo ocurre en node.

@Timer este problema

Perdí todo el día en acomodarlo, no sé cuál es el problema de origen, incluso probé la solución (que no funcionó).

¿Necesita ayuda para investigar alguna dirección?
¿Tiene algún presentimiento al respecto?
¿Por qué sucede eso solo en la construcción de producción?
¿Qué cambió de 9.0.5 a 9.0.6 que pueda estar relacionado con esto?

Gracias 🙏🏼

¡Creo que encontré el problema!
Creo que es una combinación de 2 cosas:

1. uso de sym-link para node_modules
2. i18next / react-i18next no eran externos en los paquetes de servidor !!
   
   En mi caso, cuando explota en la compilación de producción, se queja en i18next useTranslation hook ...

Así que he investigado la razón por la cual hay módulos de nodo dentro de los paquetes de servidor (la mejor práctica para los paquetes de servidor es hacerlos externos).

Vi que la siguiente tiene algunas excepciones para la siguiente biblioteca (¿por qué?), La parte divertida es que esta expresión regular captura todas las bibliotecas que terminan en next/dist/ , como lo hace i18next & react-i18next !!

Entonces, si cambia esto:

res.match(/next[/\\]dist[/\\]/) 

dentro

res.match(/[/\\]next[/\\]dist[/\\]/) 

El paquete del servidor excluirá todas las bibliotecas que no sean next y terminen con next/dist , ¡y resolvió el problema!

Para mí, el problema principal es la nueva forma en que se resuelven las solicitudes: https://github.com/zeit/next.js/blob/canary/packages/next/build/webpack-config.ts#L446

Dado que tenemos componentes fuera de la raíz del proyecto, la resolución de la solicitud arrojará un error que dará como resultado que react se incluyan en los fragmentos del servidor. Y es por eso que obtenemos el error Invalid hook call en el servidor.

@baldurh context en esa expresión que vinculó es proporcionada por webpack, y es diferente a la raíz de compilación (el directorio de su proyecto).
Siempre es el directorio del archivo que emite el requerimiento.

Correcto. He parcheado esto para que funcione para nosotros por ahora. Creo que eventualmente cambiaremos la estructura del código para que las dependencias se compartan en un nivel de directorio superior. Sin embargo, incluso si react está disponible en la carpeta externa (fuera de la raíz), sigo recibiendo el error.

Estoy intentando utilizar un paquete vinculado y estoy experimentando el mismo problema. Lamentablemente, ninguna de las correcciones de https://github.com/facebook/react/issues/13991 funciona 🙁

También estoy experimentando el mismo problema con una biblioteca de componentes enlazada simbólicamente con yarn link . Esto funcionó bien hasta v9.0.6-canary.4 y ahora estoy en la misma posición que otros comentaristas y no puedo actualizar más allá de esto. He señalado el cambio a este PR https://github.com/zeit /next.js/pull/8739

Mi biblioteca de componentes usa react , react-dom y styled-components . La configuración para esto es la siguiente

• Se agregaron los paquetes como devDependencies y se incluyeron en peerDependencies
• Agregué los paquetes como externos en mi configuración de paquete web
• Agregué resolver alias a estos paquetes en mi próxima configuración
• Transpilado el módulo de biblioteca de componentes con next-transpile-modules

Actualizar

Pude solucionar esto al incluir estos módulos en los externos del servidor. Gracias a @HosseinAgha en este comentario https://github.com/martpie/next-transpile-modules/issues/50#issuecomment -558318688

if (isServer) {
  config.externals = [
    'react',
    'react-dom',
    'styled-components',
    ...config.externals
  ]
}

Estoy viendo exactamente los mismos problemas, ninguna de las soluciones me ha funcionado hasta ahora.

Mi paquete funciona si lo publico y lo instalo (y uso resolve.alias en mi next.config.js).

Pero ejecutar una compilación de desarrollo con el paquete vinculado a través de yarn link @mypackage siempre resulta en un error de gancho no válido.

También pude hacerlo funcionar modificando node_modules/dist/build/wepack-config.js y comentando las líneas agregadas en https://github.com/zeit/next.js/pull/8739

Lo que veo si registro baseRes y res es que la condición if se activa como:

• /myApp/node_modules/react/index.js! == /myApp/node_modules/myPackage/node_modules/react/index.js
• según tengo entendido, esto se activa si la ruta no es la misma, incluso el archivo / versión es 100% idéntico

Actualizar:

Logramos solucionar el problema convirtiendo nuestro paquete para usar espacios de trabajo de hilo (aunque nuestro repositorio solo contiene un paquete).
Movimos nuestro código de ./src a ./package/our-package-name/src y configuramos los espacios de trabajo de hilo => https://classic.yarnpkg.com/en/docs/workspaces/

Esto soluciona el problema, ya que elevará las dependencias comunes al nivel superior de la carpeta ./node_modules y ./package/our-package-name/node_modules permanecerá prácticamente vacío.

Así que ahora, cuando vinculemos nuestro paquete a continuación, ya no tendremos una segunda versión de react (ya que no está presente en nuestra carpeta de paquetes node_modules) y todo funciona como debería.

Tengo el mismo maldito problema. ¬¬ '

Generalmente colapsamos al jurar porque va en contra del código de conducta.

Lo siento, estaba enojado con este error. De hecho, me gusta demasiado Next.JS. Pero no puedo usarlo porque este problema es aburrido.

Nos enfrentamos a este problema cuando trabajamos con paquetes locales externos y next-transpile-modules .

Como queremos seguir con la última versión de Next.js, intentaré enviar un parche a Next.js si encuentro la causa raíz.

Me enfrento al mismo problema, después de instalar [email protected]
Mis dependencias son [email protected] , [email protected] , [email protected] y, por supuesto, muchas otras bibliotecas (pero todo funcionaba antes de instalar next-i18next). Si alguien tiene una solución alternativa, podría ser genial: +1:

Gracias por publicar este problema, también tuve problemas con el enlace simbólico de nuestro paquete de sistema de diseño (biblioteca de componentes de reacción). También lo estamos transpilando usando https://github.com/martpie/next-transpile-modules.

La solución que se sugiere aquí funcionó para nosotros:

• Enlace simbólico su biblioteca a su carpeta node_modules (lo hicimos con nuestra propia utilidad en lugar de npm link pero debería ser básicamente lo mismo)
• Agrega algo como lo siguiente a tu next.config.js :

// next.config.js
const nextConfig = {
    webpack: (config, options) => {
        // modify the `config` here

        if (options.isServer) {
            config.externals = ["react", ...config.externals];
        }
        config.resolve.alias["react"] = path.resolve(__dirname, ".\\node_modules\\react");

        return config;
    },
};
// more plugins etc...

Nuestra solución alternativa que no requiere configuración

• Enlace simbólico todo excepto node_modules de su paquete. Creé mi propia utilidad para esto, tal vez pueda publicarla en github.

Pero sería bueno ver esto arreglado en NextJS, pasé tanto tiempo tratando de entender por qué el alias del paquete web funcionaba para todos mis proyectos que no son de NextJS :)

PD. No tengo idea de cómo afectaría esto a una compilación de producción, pero solo lo usaríamos durante el desarrollo

if (options.isServer) {
            config.externals = ["react", ...config.externals];
        }

react ya es del lado del servidor externo.

config.resolve.alias["react"] = path.resolve(__dirname, ".\\node_modules\\react");

Esto no resolverá el problema.

Como se dijo anteriormente, este problema está relacionado con sus dependencias dependiendo de react mientras que deberían tener un peerDependency en react (y react-dom si lo necesitan).

@timneutkens

Bueno, no, este no es siempre el caso. Seguro que reaccioné y reaccioné como dependencias entre pares. Sin embargo, el problema persiste si, por ejemplo, enlaza simbólicamente su biblioteca a un proyecto nextjs. Lo que sucede entonces es que tendrá una carpeta node_modules dentro de su biblioteca (al menos si alguna vez ejecutó npm i o npm link en esa carpeta de biblioteca).

Cuando reaccione se resuelva desde esta carpeta de la biblioteca, se resolverá en la carpeta node_modules y obtendrá copias dobles de reaccionar que causan el problema. Si elimino la carpeta node_modules dentro de mi lib o la instalo usando algo más que npm link entonces sí, funciona (si usa dependencias de pares o exactamente la misma versión de reacción).

Entonces, para resolver esto durante el desarrollo, debe poder reaccionar alias para obligar a todos a usar la misma versión. Debido a los problemas mencionados aquí, esto no tiene ningún efecto en la versión actual de NextJS sin agregar la parte config.externals ... (al menos para mí), probablemente como la gente ha mencionado aquí debido a algún cambio como se indica aquí # 8739?

Me está sucediendo un problema similar, pero (potencialmente) debido a la biblioteca material-ui (como se describe en # 10162), mi solución temporal por ahora era solo agregar npm run clean en mi preserve y dev scripts como se describe aquí:
https://github.com/zeit/next.js/issues/10162#issuecomment -612501431

@timneutkens Entiendo que el problema real tiene que ver con la forma en que esas dependencias enumeran sus propios departamentos (deps vs peer-dep), pero ¿alguna idea de lo que podemos hacer en nuestra propia aplicación para solucionar esto de manera más permanente?

@ ryan-0 ¿Tienes alguna configuración especial? ¿Se sorprendería si el material Ui no aparece en la lista reaccionara como un peer dep? ¿Usas una versión de reacción muy antigua o un enlace simbólico?

sin configuración especial ... sin enlace simbólico y reacciona 16.13.1 -> tenemos algunos otros departamentos que podrían estar causando que el problema sea justo, pero al menos de acuerdo con esa reproducción parece estar relacionado con material-ui / core (que también usamos):
https://github.com/zeit/next.js/issues/10162

@ ryan-0, ¿hay una carpeta node_modules con react dentro de su carpeta material-ui?

¿También comienza a funcionar después de ejecutar npm dedupe?

no, no parece que haya una carpeta de nodo anidado, por lo que estoy confundido en cuanto a cómo está sucediendo el error. y no npm dedupe no funcionó :(

Curiosamente, el uso de resolve.alias no parece afectar a los paquetes fuera de la raíz del proyecto.

Aquí está mi archivo next.config.js :

const path = require('path')

module.exports = {
  webpack: config => {
    const { alias } = config.resolve || {}
    alias.react$ = path.resolve('node_modules/react')
    alias['react-dom$'] = path.resolve('node_modules/react-dom')

    config.resolve = {
      ...config.resolve,
      alias,
    }

    return config
  }
}

Estoy usando yarn link con un paquete local que existe en un monorepo de Lerna. Su node_modules no contiene una copia de react , pero la raíz de monorepo sí . No esperaría que eso hiciera una diferencia siempre que se use resolve.alias , pero desafortunadamente ese no es el caso. Después de eliminar la copia de react de la raíz de monorepo, ahora recibo un error Cannot find module 'react' .

¿Alguien encontró una buena solución para esto?

Tengo una biblioteca siguiente vinculada que estoy usando next-transpile-modules para agregarla a mi proyecto 'consumidor'. Agregué el alias react en mi next.config.json como se menciona en sus documentos, pero no fue suficiente. Sigo recibiendo el error de dependencias duplicadas para React.

Puedes intentar usar relative-deps por @mweststrate

¿Alguien encontró una buena solución para esto?

Tengo una biblioteca siguiente vinculada que estoy usando next-transpile-modules para agregarla a mi proyecto 'consumidor'. Agregué el alias react en mi next.config.json como se menciona en sus documentos, pero no fue suficiente. Sigo recibiendo el error de dependencias duplicadas para React.

Sí, vea mi publicación anterior, debe agregar la parte config.externals en mi muestra, luego el alias comienza a funcionar nuevamente

@johot Probé tu solución pero no funcionó para mí. Comencé a recibir algunos errores extraños, pero principalmente este: cannot destructure property 'query' of 'Object(...)(...)' as it is null después de probar su solución. El objeto visto como nulo en este caso es el useRouter de next/router .

@aleclarson Gracias por la sugerencia. Lo intentaré si no puedo hacerlo funcionar con la siguiente configuración. ¿Lo estás usando actualmente?

Si está utilizando next-transpile-modules y Yarn, la solución es bastante sencilla: https://github.com/martpie/next-transpile-modules#i -have-problem-with-duplicated-dependencies-or-the -invalid-hook-call-error-in-react

Si está usando npm , todavía estoy buscando una solución: c

Ok, entonces mi solución final fue migrar de yarn link a yalc . Tengo una tarea de trago que observa los cambios de archivos y copia los archivos en mi carpeta dist y luego empuja los cambios a la tienda yalc.

En mi 'consumidor' modifiqué tsconfig.json para resolver las rutas de esta manera:

 "paths": {
      "~/*": ["/src/*"],
      "my-library/*": ["./node_modules/my-library/dist/*"]
    },

y en el next.config.js agregué lo siguiente:

 experimental: {
      jsconfigPaths: true, // enables it for both jsconfig.json and tsconfig.json
    }

Entonces, a continuación, puede resolver las rutas en función de tsconfig.json paths . Más info aquí .

En pocas palabras: la combinación de yalc + next-transpile-modules mejoró mucho mi configuración de desarrollo local. Sin dependencias duplicadas y errores extraños. El comportamiento de agregar directamente el módulo usando yarn add y vincular el módulo con yalc es prácticamente el mismo.

Si está utilizando una biblioteca vinculada localmente que depende de styled-components , consulte esto: https://styled-components.com/docs/faqs#linking -in-an-ssr-stage

En server/index.js :

const moduleAlias = require('module-alias');
moduleAlias.addAlias('styled-components', path.join(__dirname, '../node_modules/styled-components'));

Pero, también necesitábamos agregar lo siguiente en next.config.js :

config.resolve.alias['react'] = path.resolve(__dirname, './node_modules', 'react');
config.resolve.alias['react-dom'] = path.resolve(__dirname, './node_modules', 'react-dom');
config.resolve.alias['prop-types'] = path.resolve(__dirname, './node_modules', 'prop-types');
config.resolve.alias['styled-components'] = path.resolve(__dirname, './node_modules', 'styled-components');

Espero eso ayude.

Probado con:

Siguiente: 9.3.5
Reaccionar: 16.13.1
componentes con estilo: 5.1.0

Amigos, solución simple, elimine su versión global de react, next y react-dom haciendo:
npm remove -g react next react-dom

Amigos, solución simple, elimine su versión global de react, next y react-dom haciendo:

npm remove -g react next react-dom

Me alegro de que haya funcionado para usted, pero dudo que muchas personas en este hilo tengan estas dependencias instaladas globalmente.

¡No solo web!
reaccionar 16.9
react-native 0.62
Ejecutando en Android
¿Quizás el reproductor más pequeño de la historia?

import React, { Component, useState } from 'react';
import {
  AppRegistry,
} from 'react-native';

function hooker() {
  const [count, setCount] = useState(0)
}

class ClassA extends Component {
  constructor(props) {
    super(props)
    //hooker();  //Invalid hook call Error
  }
  componentDidMount(){
    //hooker();  //Invalid hook call Error
  }
  render() {
    hooker();  //Invalid hook call Error
    return (      
      null   
    );
  }
} 
export default function App(props) {
  //hooker();  //No problem
  return (
    <ClassA/>
  );
};

AppRegistry.registerComponent('default', () => App);

También enfrenté este problema y luché contra él para usar yarn lugar de npm (con npm no funcionó) y usando https://github.com/vercel/next.js/ issues / 9022 # issuecomment -616169466

¿Existe alguna solución para esto?

Simplemente atascado por completo con la versión 9.4.4.

Problema que ocurre en HOC para rutas privadas a continuación. También intenté usar withRouter pero luego se arroja el mismo error en el componente envuelto.

import { useRouter } from 'next/router'

function withPrivateRoute(WrappedComponent) {
const router = useRouter();                    //**** ERROR IS THROWN HERE *******
class WPR extends React.Component {
    componentDidMount(){
        console.log('wrappeed', WrappedComponent);
        // const { router } = this.props;
        const intendedRoute = router.pathname;
        // const isAdmin = !!cookies.get('isAdmin');
        // const isAuthenticated = !!cookies.get('username');
        const isAuthenticated = false;
        const isAdmin = false;
        if (!isAuthenticated) {
            router.push({
                pathname: '/login',
                query: { from: intendedRoute },
            });
        }
        if (
            isAuthenticated &&
            router.pathname.includes('admin') &&
            !isAdmin
        ) {
            router.push('/');
        }
    }

    render() {
        return ({ ...props }) => <WrappedComponent {...props} />;
    }
}
return WPR;
 }

  export default withPrivateRoute;

Tuve el mismo problema, así que tuve que volver a mi rama anterior (donde asumí que este problema no estaba allí) y agregar el último archivo de código por archivo y descubrí que el problema era

import { useToasts, AppearanceTypes } from 'react-toast-notifications';

export const showToast = (message: string, appearance: AppearanceTypes) => {
    const { addToast } = useToasts();
    addToast(message, {
        appearance,
    });
};

Estaba usando un servicio de brindis y en cada solicitud si hay un error aparece showToast , pero ahora con este error, no creo que vaya a usar este servicio.

Puedo confirmar que esto está relacionado con el PR https://github.com/vercel/next.js/pull/8739 por @arcanis
Estamos usando una configuración de monorepo con Rush y pnpm que elimina la razón por la que se fusionó el PR mencionado. También significa que el punto que @timneutkens hizo en https://github.com/vercel/next.js/issues/9022#issuecomment -610255555 no se aplica a nosotros, tenemos la siguiente estructura:

website
  dependencies: next, react, react-dom, library
library
  devDependencies: react, react-dom (for tests)
  peerDependencies: react, react-dom

Los library.devDependencies.(react|react-dom) son enlaces simbólicos que apuntan a exactamente los mismos archivos que website.dependencies(react|react-dom) . Sin embargo, parece [email protected] que se usa en https://github.com/vercel/next.js/blob/f98e38c9b634b85e6679e7b5f953a9d98074cfc3/packages/next/lib/resolve-request.ts#L16 no sigue el actual comportamiento predeterminado de Node.js conservando los enlaces simbólicos.

Terminamos con lo siguiente:

1. Configurando los siguientes módulos de transpile para transpilar nuestro código en library
2. Configurando resolve.symlinks = true en la configuración del paquete web dentro de next.config.js
3. Manipulación de externos solicitados desde library a solicitar desde library/node_modules (para que la compilación del lado del servidor resuelva los módulos correctamente)
4. Comentando la línea https://github.com/vercel/next.js/blob/f98e38c9b634b85e6679e7b5f953a9d98074cfc3/packages/next/build/webpack-config.ts#L601

Esto funciona según lo previsto pero se siente hack, dado que Next.js está impulsando algunos de los sitios web importantes como el de Apple, ¿ es posible esperar un mejor soporte para los monorepos que a menudo se usan para administrar el código compartido en esos grandes proyectos?

He estado jugando con estos y descubrí que, cuando uso un HOC, arroja un error, pero, si uso un componente como contenedor, funciona bien.

Si alguien está interesado, tengo un repositorio donde puede reproducir esto: next-components-hooks-error

Prueba HOC: arroja error

components/withPrivateRoute.js -> Componente de orden superior

import React, { useEffect } from 'react';
import { useRouter } from 'next/router';
const withPrivateRoute = WrappedComponent => {

    const router = useRouter();
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        const user = localStorage.getItem('user');
        console.log(user);

        if (!user) {
            router.push('/login');
        } else {
            setLoading(false);
        }

    }, []);

    return ({ ...props }) => !loading && <WrappedComponent test={test} {...props}/>;
};

export default withPrivateRoute;

pages/hoc.js -> No funciona (página usando el HOC)

import React from 'react';
import withPrivateRoute from '../components/withPrivateRoute';

const HocTest = () => <p>Authorization HOC Test!</p>;

export default withPrivateRoute(HocTest);

Prueba de componente de envoltura

components/AuthLayout.js -> Componente (envoltorio)

import React, { useState, useEffect } from 'react';
import { useRouter } from 'next/router';

const AuthLayout = ({ children }) => {

    const router = useRouter();
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        const user = localStorage.getItem('user');
        console.log(user);

        if (!user) {
            router.push('/login');
        } else {
            setLoading(false);
        }

    }, []);

    return !loading && (
        <React.Fragment>
            {children}
        </React.Fragment>
    );
};

export default AuthLayout;

pages/wrapper.js -> Página que usa el componente contenedor, funciona

import React from 'react';
import AuthLayout from '../components/AuthLayout';

const WrapperTest = () => (
    <AuthLayout>
        <p>Authorization Wrapper Test!</p>
    </AuthLayout>
);

export default WrapperTest;

Hey @Timer, ¿hay algún progreso en esto?

Resuelvo mi problema usando https://github.com/vercel/next.js/issues/9022#issuecomment -609969178 como solución.
Mis problemas fueron con el uso de mi repositorio de la biblioteca y yarn link ing con mi repositorio de aplicaciones
ejemplo
package.json

{
  "dependencies": {
    "next": "9.5.1",
    "myUILibrary": "git+ssh://[email protected]/MyRepo/library-web-ui.git#master",
    "react": "16.13.1",
    "react-dom": "16.13.1"
  }
}

y yo yarn link myUILibrary a mi pago local MyRepo/library-web-ui que también tiene react instalado.

Muchas gracias @johot por publicar tu solución

5 🌟 de 3 (¡sí! ¡Todas las estrellas y más!)

Puedo confirmar la misma experiencia que @ wasd171 en un ~9.4.4 en el ínterin.

Tengo exactamente el mismo problema con Rush + PNPM 👍

ok, tuve un error muy estúpido que causó este problema:

import React, { useState } from 'React';

Debería ser r eact en lugar de R eact:

import React, { useState } from 'react';

Sip. También veo esto en 9.5.x - La degradación a 9.4.4 funciona - También puede reproducir esto con next-site

No pude corregir este error en 9.5.2. Pero todo funciona perfectamente en 9.5.3 para mí sin ningún truco.

No estoy usando pnpm.

Hablé demasiado pronto. Tampoco creo que funcione con 9.5.3.

Ahora funciona de manera confiable en 9.5.3. 🤷 Ya no sé qué está pasando.

9.5.3 no funciona para mí - mismo error. Estoy usando Rush + NPM. ¿Existe una solución alternativa conocida? (por cierto, actualice el título porque ya no se trata de 9.0.6)

Para su información, fue una de las razones por las que mi organización decidió pasar de npm a yarn . Simplemente (desafortunadamente) juega mucho mejor. La mudanza es molesta, pero ahora estamos bastante contentos.

Los módulos transpilados con ganchos tampoco me funcionan.

Por cierto, para cualquiera que experimente este problema al usar next-transpile-modules y npm , escribí una sección de preguntas frecuentes que explica el problema y las posibles soluciones: https://www.npmjs.com/package/ next-transpile-modules # i-have-problem- with-duplicated-dependencies-or-the-invalid-hook-call-error-in-react

Logré resolver esto agregando manualmente la resolución de la versión para hilo en la raíz del proyecto. Entonces, en lugar de mover todas las dependencias de reacción a la raíz package.json , agregué las siguientes líneas:

  "resolutions": {
    "react": "16.13.1",
    "react-dom": "16.13.1"
  }

Ver: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

Vale la pena señalar que en mi caso, las compilaciones locales funcionaron mientras que las compilaciones en Vercel informaron el error Invalid hook call .

Experimenté un problema similar en _app.js con una página general en Next 10

Oye,

En mi caso, había transpilado módulos que también estaban vinculados a través de npm link .

Las dependencias como React deben incluirse como peerDependencies lugar de las dependencias regulares porque estaba descargando varias instancias de la misma. Entonces, si tiene el error de ganchos no válidos, intente estos pasos:

1. Incluya su módulo de terceros como una dependencia en su proyecto principal.
2. Ejecute npm install para instalar todos sus módulos.
3. Abra su terminal / consola y navegue hasta el módulo, luego ejecute sudo npm link .
4. Vuelva a su proyecto principal y ejecute npm link @example/project . Debería ver un pequeño icono de flecha cerca del nombre de su módulo dentro de node_modules si está usando Visual Studio Code.
5. Ejecute su npm run dev .

Nuevamente, debe incluir React como peerDependency en lugar de una dependencia regular en su @ example / project.

¡Espero que eso ayude!

Tengo un monorepo con un proyecto next.js adentro. Se enfrentó al mismo problema con una llamada de gancho no válida después de instalar storybook . Resolví el problema siguiendo la sugerencia de resolutions al nivel raíz package.json :

"resolutions": {
  "react": "^17.0.1",
  "react-dom": "^17.0.1"
}

Sin embargo, no estoy seguro de si esa será una buena solución una vez que agreguemos más clientes y paquetes.