reactjs - tablas - tipos de componentes existentes en react

¿Por qué necesita importar Reaccionar varias veces en componentes principales y secundarios?

Question

Si tiene un archivo de componente principal que ya importa React , ¿por qué alguno de sus archivos secundarios prestados también necesita importar Reaccionar? ¿Es solo una medida de seguridad en caso de que esos niños se rindan alguna vez en otro lugar donde React no se haya importado todavía?

Answer 1

El motivo es evitar la compilación innecesaria de un código JavaScript que no tiene que compilar jsx. Por ejemplo, si tiene un archivo que tiene una función para agregar, o cualquiera que sea la función que no necesite compilar jsx, entonces no debe poner la importación Reaccionar de ''reaccionar'' en la parte superior de ese archivo. Esto te ahorrará tiempo de compilación.

Answer 2

En nodejs cada archivo es un módulo, que tiene su propio alcance de variables. Cuando importa variables en archivos (por ejemplo, React ) agrega esta variable al alcance del módulo, pero no al alcance global.

En el caso de un webpack , puede usar providePlugin para hacer fácilmente variable global de React :

new webpack.ProvidePlugin({
React: ''react'' // ReactJS module name in node_modules folder
})

Después de eso, puede omitir la importación de la variable React en todos sus módulos. Webpack lo hará por sí mismo cuando sea necesario.

Answer 3

La raíz de la pregunta es la gestión de la dependencia: ¿cómo yo, el autor, describo y obtengo las dependencias externas que necesito en mi "cosa" (aplicación / componente / módulo) para que haga su trabajo?

JavaScript se beneficia (o sufre) de tener un espacio de nombres global en el que se pueden inyectar dependencias. Si bien esto a menudo puede simplificar la administración de dependencias en el corto plazo (por ejemplo, puede ignorarlo y esperar que todo lo que necesita esté disponible en el espacio de nombres global), a menudo puede causar problemas a medida que una aplicación crece y cambia. Por ejemplo, dada una aplicación con múltiples colaboradores, uno podría decidir cambiar una parte de la aplicación para que ya no use una dependencia particular y, por lo tanto, eliminarla. Si otra parte de la aplicación lo necesitaba pero esa dependencia no se declaró formalmente en ningún lugar, podría pasarse por alto fácilmente.

Para hacer bien la gestión de la dependencia, cada "cosa" discreta debería describir sus dependencias independientemente de cualquier otra "cosa", de modo que pueda usarse con seguridad en cualquier contexto dado. Esto garantiza que cada "cosa" tenga exactamente lo que necesita sin importar cómo se use y qué tiene su "padre" (el código que importa la "cosa").

Una alternativa a este enfoque es la inyección de dependencia. En este modelo, la "cosa" proporciona una interfaz para pasar las dependencias a la "cosa" del consumidor. Existen ventajas de flexibilidad y capacidad de prueba que están fuera del alcance de su pregunta. :)

// export a function that expects the React and PropTypes
// dependencies to be injected as parameters and returns
// the component rather than importing the dependencies
// and exporting the component
export default (React, PropTypes) => {
return class extends React.Component {
static propTypes = {
name: PropTypes.string.isRequired
}
render () {
return (
<div />
);
}
};
};

Todo eso para decir, de alguna manera es una "medida de seguridad" tener cada "cosa" importar sus propias dependencias. Le permite refactorizar de forma segura su código sin la carga cognitiva de recordar qué está proporcionando esas dependencias.

Answer 4

Si usa JSX y babel , debe importar React en cada archivo porque babel-preset-react transpilará su código JSX en React.createElement() a React.createElement() , por lo que este código

const Foo = () => <h1>Test</h1>;

estarán

var Foo = function Foo() {
return React.createElement(
"h1",
null,
"Test"
);
};

DEMO: Babel REPL

Esta es la razón por la cual React debe ser accesible en el ámbito adecuado y una forma de hacerlo es importar Reaccionar en un archivo.