La putada del estate es que todo lo que use el state se va a re-renderizar si cambias cualquier cosa (cosa que con redux no pasa). Yo guardaría solo el usuario, preferencias y poco más.
Creo que eso no tiene nada que ver, y vas a tener mas o menos los mismos re-rerenders que con Redux, funcionan idéntico.
#271 creo que no, que redux solo re-renderiza las cosas que usen el estate que ha cambiado, pero podria equivocarme (he conseguido no tener que usar redux por ahora)
#270 Evidentemente, si la data es super dinámica, y puede cambiar a segundos, cada vez que tengas que montar un selector debes hacer fetch de ella.
#272 Estas equivocado, ambas renderizan lo mismo, por algo Facebook esta trabajando en Recoil, que hace eso que tu dices.
https://dev.to/narendersaini32/recoil-a-new-state-management-library-from-facebook-for-react-3095
Aprovechando el tema de estados, que estoy empezando a hacer pruebas y demás en React con lo que llevo visto (igual hay otras maneras xD)
¿Qué es mejor, tener un "useState" por cada variable que cambie, o tener un único "useState", con un objeto grande (y tener que pasarlo entero con cada modificacion)?
Pongo un ejemplo en código:
#275 La opción 2 nunca.
Luego si solo modificas 1 estado cada vez que ocurre algo, la opción 1 es la correcta.
Pero si por ejemplo, cuando el usuario hace click en X haces dos cosas, modificar articulos y notificaciones, entonces lo mas optimo es crear un reducer, de tal forma en lugar de hacer:
onClick= () => {
setNotifications(1)
setArticulos(blabla)
}
Tienes un reducer y le lanzas un dispatch:
onClick = () => dispatch({type : 'ADD_NOTIFICATION_AND_MODIFY_ARTICLE', payload : { notification : 1, article : blabla}})
Con el useReducer puedes modificar dos estados o los que quieras y solo provocar 1 re-rerender, de la otra forma generaras 2, y lo que es peor, te expones a los race condition.
#277 Es cristalino:
https://reactjs.org/docs/hooks-reference.html#usereducer
useReducer is usually preferable to useState when you have complex state logic that involves multiple sub-values or when the next state depends on the previous one. useReducer also lets you optimize performance for components that trigger deep updates because you can pass dispatch down instead of callbacks.
#273 Yo me he hecho algo muy similar con rxjs, un custom hook que hace setState de un obsv mapeado, que solo setea el state si cambia algo del estado (shallow+distinctUntilChanged). Y así solo se re-renderizan los componentes en los que realmente ha cambiado algo.
#279 Yo estoy con este curso y es bastante completo: https://udemy.com/course/complete-react-developer-zero-to-mastery
Haced caso a uno de los padres, Don KCD.
Pedid a vuestros jefes que os compren: https://epicreact.dev/
Duda:
Existe en NextJS alguna manera de configurar manualmente una ruta para que vaya a un componente? (sin crear la estructura de /pages).
Por ejemplo, con esta estructura:
Me gustaría hacer que la ruta /product/:id cargue /pages/products/edit.js , pero sin necesidad de renombrar el edit.jsx a [id].jsx
Aunque desconozco si se puede xD
Sip, además de Angular, tiene react, react native, Vue, AWS, Svelte.... xD
Si haces click en su nombre salen todos los cursos 
#285 Creo que no, que en Nextjs el router solo mira los archivos en la carpeta pages.
Lo que no se si podras crear una carpeta [id] con dos archivos create.js edit.js
Algo asi :
edit: https://nextjs.org/docs/routing/introduction#dynamic-route-segments
#286 Pues investigaré un rato más a ver si encuentro la manera y, si no, probaré con lo que dices =)
#285 Puedes, pero de forma "extra oficial" .
Mapeas los componentes en un objecto, y apuntas a / con un parametro que se identificativo de ese componente, entonces renderizas /pagina-con-componente, y dentro tendrás solo ese componente.
Evidentemente tienes que extender la funcionalidad de /index.js para que sea capaz de entender que esta no es una pagina de /pages pero una pagina custom con componentes dinámicos.
Explicado de forma rapida y cutre, pero básicamente es así, nosotros lo hacemos en nuestro proyecto del curro para poder montar paginas con componentes custom como si de un wordpress se tratara, donde el usuario elige que componentes quiere en cada row de X pagina.
#273 Estas equivocado, redux y context no actuan igual a los cambios de state, tiene razón #272
Por eso no es tan sencillo como ¿Para que usar redux si ya hay context+hooks?. Redux lleva por debajo optimizaciones por defecto, en cambio en un context+hooks (datareducer de tu ejemplo), si cambias algo en tu provider, todos los componentes que usen "useContext" (de ese provider) se rerenderizan, independientemente de que estén usando o no "la parte en concreto" que has modificado.
En la mayoría de casos va a ser irrelevante estos rerenders, puesto que se ejecutan en dispositivos que no tienen problemas de rendimiento (navegador web en un pc, react-native en dispositivos actuales, etc ..), pero te puedo asegurar que en dispositivos con recursos mucho más limitados, esos renders extras pueden llegar a afectar bastante
Por no hablar de ciertos middlewares gracias a Redux, que por supuesto puedes montarte tu una implementación si quieres usando context y demás, pero vamos, que es un ecosistema más maduro y que sigue teniendo cabida, a pesar de que mucha gente diga que no hace falta.
Que de movimiento hoy, tengo que sacar un ratito para leerme las últimas páginas bien.
#281 #282 Me alegra ver que no soy el único pringui pegado todo el día a Udemy!
Yo ya he acabado este curso: https://www.udemy.com/course/modern-react-bootcamp/ Y lo recomiendo al 100%, por lo menos para n00bies como yo ya que tiene muchos ejercicios para practicar lo que se enseña cada lección.
Con el curso acabado sigo como estaba en #233 though.
#290 #289 I agree to disagree, Redux per se lleva ciertas optimizations gracias al Connect que tiene, pero no hace magia, si tu modificas el elemento mas elevado en un árbol, todos sus descendientes se van a re-renderizar, no hay vuelta de hoja en esto, sea Redux o context.
Dicho esto, si las re rerenderizaciones son costosas, aquí nuestro querido Dan Abramov nos explica en pocos lineas, como aun así, no necesitas Redux:
https://github.com/facebook/react/issues/15156#issuecomment-474590693
#292 Esta dando alternativas para evitar precisamente los re-renders, y en ningún sitio pone que no sea necesario Redux.
Si usas un provider para guardar por ejemplo un listado de elementos que puedes modificar de manera individual, las opciones según las alternativas:
Redux per se lleva ciertas optimizations gracias al Connect que tiene, pero no hace magia, si tu modificas el elemento mas elevado en un árbol, todos sus descendientes se van a re-renderizarRedux en React lleva implícito el uso de React-redux, con lo cual siempre vas a usar connect, que es donde reside "la magia" y optimizaciones para que tus componentes no se re-rendericen si no es necesario
Y a todo esto hay que añadir todo lo que viene de la mano de redux, muchos middlewares ya creados y ampliamente utilizados por la comunidad, debugging, etc. Que es básicamente lo que ha dicho #290
Reafirmo lo dicho
Vengo a hacer un rant rapido.
Mi empresa busca Lead Frontend
Candidato que nos presentan es un Lead de Aplicaciones hechas en Kotlin sin puta de idea de arquitectura de Frontend y React.
Todo el equipo no le gusta excepto al CTO y COO.
Mi unica cuestion es, este pabo es el puto amo 69 si tiene los huevazos de venderse tan bien en una posicion que no tiene ni puta idea.
