Te doy la bienvenida a nuestra página web, aquí vas a encontrar la respuesta a lo que estabas buscando.
Solución:
Creo que no entiendes qué es “nivel superior”. Simplemente significa que, dentro de un componente funcional, useSelector()
no se puede colocar dentro de bucles, condiciones y funciones anidadas. No tiene nada que ver con el componente raíz o la estructura de los componentes.
// bad
const MyComponent = () =>
if (condition)
// can't do this
const data = useSelector(mySelector);
console.log(data);
return null;
---
// good
const MyComponent = () =>
const data = useSelector(mySelector);
if (condition)
console.log(data); // using data in condition
return null;
Si algo, mapStateToPtops
se encuentra en un nivel incluso más alto que una llamada de gancho
las reglas de los ganchos hacen que sea muy difícil usar ese gancho específico. Todavía necesita acceder de alguna manera a un valor cambiante del estado dentro de las devoluciones de llamada
Para ser justos, casi nunca tienes que acceder al valor cambiante dentro de una devolución de llamada. No recuerdo la última vez que lo necesité. Por lo general, si su devolución de llamada necesita el estado más reciente, es mejor que envíe una acción y luego el controlador de esa acción (redux-thunk, redux-saga, redux-observable, etc.) accederá al estado más reciente.
Esto es solo información específica de los ganchos en general (no solo useSelector) y hay muchas formas de evitarlo si realmente lo desea, por ejemplo
const MyComponent = () =>
const data = useSelector(mySelector);
const latestData = useRef()
latestData.current = data
return (
¿Cuáles son los beneficios de usar el gancho además de guardar líneas de código en comparación con mapStateToProps?
- Ahorra tiempo al no escribir la función de conexión cada vez que necesita acceder a la tienda y al eliminarla cuando ya no necesita acceder a la tienda. No hay envoltorios interminables en reaccionar devtools
- Tiene una distinción clara y no hay conflictos entre los accesorios que provienen de connect, los accesorios que provienen de los padres y los accesorios inyectados por envoltorios de bibliotecas de terceros
- A veces, usted (o los compañeros desarrolladores con los que trabaja) elegiría nombres poco claros para los accesorios en
mapStateToProps
y tendrás que desplazarte hastamapStateToProps
en el archivo para averiguar qué selector se utiliza para este accesorio específico. Este no es el caso de los ganchos donde los selectores y las variables con datos que devuelven están acoplados en la misma línea - Al usar ganchos, obtienes ventajas generales de los enganches, la mayor de las cuales es poder acoplarse y reutilizar la lógica con estado relacionada en múltiples componentes
- Con
mapStateToProps
normalmente tienes que lidiar conmapDispatchToProps
que es aún más engorroso y más fácil de perderse, especialmente leer el código de otra persona (¿forma de objeto? ¿forma de función? bindActionCreators?). Prop procedente demapDispatchToProps
puede tener el mismo nombre que el creador de la acción pero una firma diferente porque se anuló enmapDispatchToprops
. Si usa un creador de acciones en varios componentes y luego cambia el nombre de ese creador de acciones, estos componentes seguirán usando el nombre antiguo proveniente de los accesorios. La forma del objeto se rompe fácilmente si tiene un ciclo de dependencia y también tiene que lidiar con el sombreado de los nombres de las variables
.
import getUsers from 'actions/user'
class MyComponent extends Component
render()
// shadowed variable getUsers, now you either rename it
// or call it like this.props.getUsers
// or change import to asterisk, and neither option is good
const getUsers = this.props
// ...
const mapDispatchToProps =
getUsers,
export default connect(null, mapDispatchToProps)(MyComponent)
Consulte EDIT 2 al final para obtener la respuesta final.
Dado que nadie sabe cómo responder, parece que la mejor respuesta es que NO debería usar useselector cuando necesite información en otros lugares que no sean el nivel raíz de su componente. Como no sabe si el componente cambiará en el futuro, simplemente no use useselector en absoluto.
Si alguien tiene una respuesta mejor que esta, cambiaré la respuesta aceptada.
Editar: se agregaron algunas respuestas, pero solo enfatizan por qué no debería usar useselector en absoluto, hasta el día en que las reglas de los ganchos cambien, y también podrá usarlo en una devolución de llamada. Dicho esto, si no desea usarlo en una devolución de llamada, podría ser una buena solución para usted.
EDITAR 2: Se agregó una respuesta con ejemplos de todo lo que quería y mostró cómo useSelector
y useDispatch
son más fáciles de usar.
El estado de la tienda Redux se puede leer y cambiar desde cualquier lugar del componente, incluidas las devoluciones de llamada. Siempre que se cambia el estado de la tienda, el componente se vuelve a reproducir. Cuando el componente se vuelve a reproducir, useSelector se ejecuta de nuevo y le proporciona los datos actualizados, que luego se utilizarán donde desee. Aquí hay un ejemplo de eso y un uso de useDispatch
dentro de una devolución de llamada (después de una asignación en el nivel raíz):
function Modal( children )
const isOpen = useSelector(state => state.isOpen);
const dispatch = useDispatch();
function handleModalToggeled()
// using updated data from store state in a callback
if(isOpen)
// writing to state, leading to a rerender
dispatch(type: "CLOSE_MODAL");
return;
// writing to state, leading to a rerender
dispatch(type: "OPEN_MODAL");
// using updated data from store state in render
return (isOpen ? (
children
) : (
);
);
No hay nada que pueda hacer con mapStateToProps / mapDispatchToProps que no pueda hacer con los ganchos useSelector y useDispatch también.
Dicho esto, hay un par de diferencias entre los dos métodos que vale la pena considerar:
- Desacoplamiento: con mapStateToProps, la lógica del contenedor (la forma en que se inyectan los datos de la tienda en el componente) está separada de la lógica de la vista (representación del componente). useSelector representa una forma nueva y diferente de pensar acerca de los componentes conectados, argumentando que el desacoplamiento es más importante entre los componentes y que los componentes son autónomos. ¿Cual es mejor? Veredicto: no hay un claro ganador. fuente
- DX (Experiencia de desarrollador): usar la función de conexión generalmente significa que debe haber otro componente contenedor adicional para cada componente conectado, donde usar los ganchos useSelector y useDispatch es bastante sencillo. Veredicto: los ganchos tienen mejor DX.
- “Accesorios obsoletos” y “Niño zombi”: hay algunos casos extremos extraños con useSelector, si depende de los accesorios, donde useSelector puede ejecutarse antes de que aparezcan los accesorios actualizados más nuevos. Estos son casos extremos raros y evitables, pero habían sido ya funcionó en la versión de conexión anterior. veredicto: connect es un poco más estable que los hooks. fuente
- Optimizaciones de rendimiento: ambos admiten optimizaciones de rendimiento de diferentes formas. connect tiene algunas técnicas avanzadas, usando accesorios de combinación y otras opciones ocultas en la función de conexión. useSelector acepta un segundo argumento: una función de igualdad para determinar si el estado ha cambiado. veredicto: ambos son excelentes para el rendimiento en situaciones avanzadas.
- Tipos: usar mecanografiado con connect es una pesadilla. Me recuerdo escribiendo febrilmente tres interfaces de accesorios para cada componente conectado (OwnProps, StateProps, DispatchProps). Los ganchos de Redux admiten tipos de una manera bastante sencilla. veredicto: los tipos son significativamente más fáciles de trabajar usando ganchos.
- El futuro de React: Hooks son el futuro de react. Esto puede parecer un argumento extraño, pero el cambio al ecosistema está a la vuelta de la esquina con el “Modo concurrente” y los “Componentes del servidor”. Si bien los componentes de clase seguirán siendo compatibles en futuras versiones de React, las nuevas características pueden depender únicamente de los ganchos. Por supuesto, este cambio también afectará a las bibliotecas de terceros en el ecosistema, como React-Redux. veredicto: los ganchos son más a prueba de futuro.
TL; DR – Veredicto final: cada método tiene sus méritos. Connect es más maduro, tiene menos potencial para errores extraños y casos extremos, y tiene una mejor separación de preocupaciones. Los ganchos son más fáciles de leer y escribir, ya que se colocan cerca del lugar donde se utilizan (todo en un componente autónomo). Además, son más fáciles de usar con TypeScript. Finalmente, serán fácilmente actualizables para futuras versiones de React.
Sección de Reseñas y Valoraciones
Si guardas algún contratiempo o capacidad de reaccionar nuestro tutorial puedes escribir una explicación y con deseo lo observaremos.