#58 Mi intención no es usarlo, el codigo me parece ugly de cojones, pero no entendía como sobrescribia el styled y seguia funcionando.
No sabia eso de curry. Voy a leer
Pillo sitio.
Después de trabajar casi tres años con React, solo puedo decir:
1) Odio Redux, huid de el si estáis a tiempo
2) Evitad contextos lo máximo que podáis
3) https://dan.church/
#63 Nuestro gran salvador.
https://overreacted.io/es/
#62 Me gusta como has tirado a la basura dos de las mejores maneras de gestionar estados en una pagina. El problema no serás tu amigo o tus compañeros? Yo trabajo con Redux en el trabajo y si se hace bien no es doloroso, todo lo contrario.
#64 Para gestionar estados, está el estado en si 
. En mi experiencia, el componente en el que se crea un estado es el que de normal ha de gestionar a este. Ni en sus hijos, ni en sus padres, ni en ningún otro sitio.
Si necesitas pasarlo por props, utiliza props drill antes que Redux o contextos.
Si necesitas pasar ese estado por props muchas veces, algo no se está haciendo bien.
Redux añade una complejidad a mi juicio innecesaria y que acaba dando más quebraderos de cabeza que otra cosa, y que seguramente en el 95% de los proyectos no se necesita.
Varias veces he tenido que coger proyectos que tenían Redux implementado, y seguir la trazabilidad del código era infumable. Que forma de hacer sobreingeniería cuando no hace falta.
Pero como digo, es mi opinión. Entiendo que haya gente que le guste, pero me alegro que Redux se esté muriendo. Con Redux he tenido amor, odio, alegría, y ahora tengo el más rechazo absoluto 
. De hecho llevo sin tocarlo mucho tiempo de lo innecesario que resulta.
#65 Te puedo comprar ciertas cosas, pero por ejemplo, la sesión de usuario,me esta diciendo que vas a pasar la sesión de usuario desde el App.js hasta el label en el header que muestra su username?
Y ojo, estoy de acuerdo que hay mucha sobreingenieria, pero yo creo que no es cosa de Redux, o culpa de redux, es porque se esta haciendo unos malabares terribles para hacer paginas en JS/React cuando hay soluciones de +15 a;os con PHP, Rails, Django que son mas solidas y te hacen el trabajo mejor y sin convertirte el codebase en un mess de HOCs infumable, pero no son the new hot thingy asi que todos para React/NextJs.
De todas formas también te digo, que con hooks se ha aligerado bastante este problema de los HOCs. Pero hay mucho codigo tirado ya, y la gente fuma mucha hierba incluso con hooks
#66 Tienes razón, hay casos muy concretos en los que no puedes huir de ello, que remedio. Tu ejemplo es muy bueno, y es un hecho que es un salvavidas cuando necesitas variables en un estado global de la aplicación, pero ese estado debería tener los mínimos datos posibles.
De todas formas, tampoco usaría Redux para un Header con el ejemplo que has dado.
¿Cuantas veces has de pasar por props desde el App.js al componente Header de turno? Como mucho, ¿dos, tres veces? Como he comentado, si se tiene que pasar a muchos niveles el mismo prop, algo no se está haciendo bien. ¿Por dos niveles vas a meter Redux o Context? Pues no se, yo no lo haría.
Influye mucho como tengas estructurado el proyecto también. Pero para casos muy específicos (y creo que no he encontrado muchos más casos más allá de información sobre la sesión de un usuario), entiendo el tener que utilizarlo.
¿Sabes cual creo que es el problema? Que cuando pegó el petardazo React, Redux era la niña bonita. Y la gente utilizaba Redux sin entender a ciencia cierta como se usaba React, y entremezclaban muchos conceptos entre ellos.
Quizás en un tiempo vuelva a usarlo y me vuelva a gustar. De momento sigo en mi burbuja intentando aplicar el principio KISS
Que vamos, en modo RPV, todos nos fumamos mucha hierba al final jajaja.
#65 Props drill es bien, pero creo que si se usa en exceso creas spaghetti.
En mi caso lo uitilizamos para mantener los datos de la api en la aplicación sin la necesidad de hacer petis innecesarias, además de mantener información global en estado que necesitará toda la aplicación y no quiero usar hocs para cada componente.
El caos que Redux es super fácil de hacerlo mal, demasiado fácil, esa facilidad crea problemas.
He leido mucho codigo que muta y remuta el estado y es porque la gente no tiene ni puta idea de JavaScript y Redux es JavaScript, no React.
Hay de todo, pero al final es saber todas las opciones y usar lo que mas te guste y lo que las empresas se ajusten.
#68 Estoy totalmente de acuerdo, props drill hasta un cierto punto. Ahí es lo que quería decir con "Evitad contextos lo máximo que podáis", todo tiene un tope.
Pero si tengo que elegir como estás comentando, prefiero Redux antes que HOCs, también tengo que decírtelo jajajajaja.
Mi primer proyecto con Redux fue heredado de una startup donde el programador era un pobre diseñador que tuvo que aprender React + Redux en el mínimo tiempo posible el solo para hacerlo lo antes posible. Entonces todos (absolutamente todos) los estados de la APP iban directamente a Redux, por falta de tiempo y por salir al paso. De ahí a que le cogiese manía, para que me entiendas 
Vamos, que al final pienso igual que tú, solo que yo prefiero tocarlo lo mínimo posible.
El context lo he usado unas cuantas veces y la verdad es que muy contento con el resultado, muy sencillo y fácil de usar. No se como estará el asunto si escala mucho.
#69 Todos los proyectos en empresas de Redux han sido heredados entiendo ese sentimiento.
A mi lo que me pasa con el contexto que lo utilizado cuando tengo que pasar 3-4 props en modo drillin y no quiero parecer una excavadora. Y cuando me acuerdo que existe xDDDDDDD
El contexto creo que lo venden los gurus como el transcedesor de Redux, cosa que es errónea, es más bien posibles componentes que estan en un componente mayor o container/view porque es logico que esten ahí pero 1+N necesitan esos mismos props, por general cuando afectan a la api o cosas así es idoneo, para no tener que hacer drilling de unas llamadas de apis en raw. Pero utilizarlo como gestor de estados como useState de children, es contraproducente porque solo entenderás el context si vas al padre. Lo tipico, hacer el codigo y volver después de 3 meses y decir "porque esto recibe esta información", si no encuentras el context rápido es sphagetti.
#70 Es lo que siempre defiendo, Redux es bueno, si se sabe poner bien y gestionar. Para eso esta el puto code review xD
#70 La idea de Redux es cojonuda, para mi es brillante. La forma de implementarlo junto a su complejidad es lo que echa p'atras. Si tito Dan inclusive no se aclara con su propio código con el paso del tiempo, por algo será (estaría bien preguntarle si sigue utilizándolo en su día a día, por curiosidad)
La verdad es que me reí cuando vi sus tweets
Redux (o equivalente) es necesario en cualquier aplicación que tenga algo de complejidad, ya no solo para casos como pasar el nombre de usuario a la cabecera, sino algo tan básico como reutilizar información de una navegación a otra, sistemas de cache, lógica mas compleja, middlewares (thunks, sagas...), etc
Desde mi punto de vista el problema es que tiene un boilerplate que echa para atrás y que mucha gente no ha terminado bien de entender como funciona o como debería usarse
React Context esta bien (de hecho es lo que usa Redux por debajo) y es mucho mas sencillo de usar, pero no hay que olvidar que Redux por debajo esta ya optimizado. Usar solo Context como reemplazo general de Redux puede disminuir el rendimiento de manera considerable en según que casos
Para resumir (y sabiendo que no todos los proyectos son iguales):
- Estructura sencilla y pocas actualizaciones (usuario logueado, theme, language, ... ) -> React context
- Estructura mas compleja, actualizaciones mas frecuentes -> Redux
Debo ser el único de por aquí que está en contra utilizar Redux como algo básico, vaya. Yo no pienso igual que #75. No es necesaria en cualquier aplicación que tenga complejidad, como he dicho, el 95% de los proyectos no deberían ni introducirlo (y diría hasta el 99%). Lo mismo con Context.
Los estados deberían manejarse de forma local, no de forma global. Y si algún newbie nos lee, de verdad os digo, pasad de Redux hasta el final y que tengáis los conceptos muy claros
Os recomiendo la lectura de You Might Not Need Redux.
He trabajado en aplicaciones muy grandes en NextJS y CRA sin tocar Redux. Y la aplicación que he comentado en #69, al final quitamos Redux de absolutamente todos los lugares, excepto para dos estados globales.
De verdad, no es tan necesario como pensais. Es mejor planear bien la estructura del proyecto y el código, a introducir algo tan complejo que a la larga no va a escalar correctamente.
Local state is fine. Don't use Redux until you're absitively, posilutely sure you need it.
Los estados deberían de manejarse de forma local, no de forma global.
Nadie está diciendo que no se deban manejar los estados de forma local, se está diciendo que para cuando tienes cierta complejidad Redux es una gran herramienta.
En serio, a veces parece que Redux hubiera matado a vuestras familias JAJ
#77 Bueno, tomatelo como quieras
Parece que te ofenda que haya gente con diferente perspectiva, yo ya he dicho que Redux es muy bueno, pero no es tan necesario como pensamos, es para casos muy específicos y que no puedas huir de ello. Y eso sucede cuando cierta complejidad en tu aplicacion es muy alta, y eso sucede a cuentagotas si la app esta bien estructurada.
Simplemente estoy dando mi opinion y quiero compartirla después de haber trabajado mucho y haberme dejado los huevos pelaos' con Redux. #71 ha compartido su vision y, tal cual lo plantea, veo cojonudo usar Redux. Pero el tiene los conceptos muy muy claros y tambien se habra peleado muchisimo con ello.
Sobre todo, me gusta compartirlo por si hay alguna persona que se anima a probar React por primera vez y esta confuso sobre si ha de utilizar Redux o no en sus comienzos 
Voy a hacer un TOCHO sobre este tema me parece muy interesante vuestra discusión. He aprendido muchas palabrotas.
Mi experiencia: A mi me ense;aron que si tu aplicación tiene push de servidor (websockets, sse), pull (hace polling de multiples APIs) y ademas estan las entradas de usuario, hazlo funcional (ngrx/redux gracias mediavida eterno pajeet). En mi caso todas las apps tienen estos 3 y tener 2 de estos elementos me parecen la gran mayoria, quizas vivo en las excepciones.
intencion vs estilo: Se esta mezclando por aquí constantemente la INTENCION con el ESTILO DE PROGRAMACION. Intentas simplificar la gestión de estados**, lo programas/usas de esta manera. Dos temas completamente distintos que sus soluciones no son excluyentes. No + coments de mi parte.
** Se utiliza para mas cosas pero la base es la misma, solo es composición funcional.
Ahora solo otro comentario sobre redux en el aprendizaje.
Yo pienso que mnDI tiene razón en que hay que aprender react primero y después decidir si se quiere seguir con redux. Resuelven problemas distintos. El problema que veo esta en los tutoriales, son ideas super sencillas y básicas... Que si que la teoría usa matemáticas y es abstracta y nadie se la lee... pero cambiar esas palabras abstractas por "reducers", "drills", "contexts", "hooks" y demás sin entender realmente lo que haces no facilita el aprendizaje. Tienes que "aprender" lo mismo o mas. Por lo que me dice todo el mundo, la gente que la lía con redux o no lo sabe utilizar no entiende la base. Igual que la gente la lía con js a pelo... Problema estructural del campo. No mas coments siempre lloro de este tema así que creo que esta clara mi opinión, en su día ya abrí un hilo llorando. Yo tarde 2 dias en llevar ngrx al toque, 0 lios.
Para terminar veo necesario comentar sobre lo que no estoy NADA de acuerdo y he leído a varios, simple != fácil, complejo != difícil.
- Fácil y difícil sabemos lo que significa. Y se progresa con experiencia Y teoria.
- Simple, viene de simplex (griego) y significa, recuerdo*, una unidad/tarea/recurso/componente.
- Complejo, del griego igual, significa entrelazar/entrelazado.
- Un sistema complejo es un sistema que entrelaza muchos componentes.
** S/o ricky
Tanto React/Redux sirven para reducir la complejidad porque desenlazan los side-effects, las acciones, los eventos, el rendering... Internamente la idea es la misma.
Since render functions and class constructors shouldn’t have side effects (which is also important for server rendering), this should not pose any practical problems.
Va haber un monton de apps que petarán.
#77 Lo que mdDI quiere llegar a decir es que al final, mucha gente decidió en su momento meter Redux en aplicaciones cuando no tienen ni puta idea y si se basa la aplicación en Redux al 100% es una basura. Llevamos hablando que esta bien hacer drilling, context pero al final lo que diferencia un React Senior a un React Junior es el concepto de saber como ejecutar todas sus herramientas de manera correcta y hacer magia.
#78 Bro me has sacado una sonrisa con el halago. (Esta de puta madre que te reconozcan tus conocimientos yo know)
#79 Menos tochoposts y más blog cabrón.
#79desu:A mi me ense;aron que si tu aplicación tiene push de servidor (websockets, sse), pull (hace polling de multiples APIs)
Más bien porque rehacer un sistema para mantener el estado global de la aplicación es algo...idiota, entonces utilizas Redux para poder facilitarte la vida pero debes de saber gestionarlo. Actualmente tenemos useSWR que es asquerosamente asombroso, mirarlo si no sabeis lo que es. Aun así es posible que le falte una vuelta para hacer un buen sistema de consistencia de datos sin pedir petis de manera innecesaria.
#79desu:Dos temas completamente distintos que sus soluciones no son excluyentes. No + coments de mi parte.
Esto es incorrecto, el estado es la aplicación y el estilo de programación no afecta porque React tiene una manera de trabajar muy concreta. Que curiosamente es hacía funcional. Lo que pasa es que estamos comentando que hacer las maneras diferentes de gestion de estados afecta directamente a su programación y visualización en arquitectura, una app de Redux no tiene nada que ver con una app de Contexts nativos a saco.
#79desu:Yo pienso que mnDI tiene razón en que hay que aprender react primero y después decidir si se quiere seguir con redux.
Añado. Javascript -> Redux(sin react) -> React
Por qué? Redux en si es logica de estados, un state machine a lo grande, react-redux lo conjunta. No tiene nada que ver con React y en si es puramente JavaScript.
#79desu:Para terminar veo necesario comentar sobre lo que no estoy NADA de acuerdo y he leído a varios, simple != fácil, complejo != difícil.
Cuando esta mal hecho sí. Nosotros en mi empresa tenemos una store con casi 30 reducers, debido que es un CRUD para que pueda mantener datos el usuario cada ruta que vaya nueva se quede guardado. Y lo que vengo a decir, somos tres en el equipo de JavaScript y es un sistema muy facil de crear Redcuers y su lógica sin liarla. Aparte soy bastante estricto a llevar la capa de logica a una capa de abtracción adicional en vez de meter muchas lineas en el reducer y me tomo mi tiempo cuando hacemos esto para testearlo(no quiero mutajes raros), porque aunque me gustaría añadir tests físicamente no tenemos tiempo.
#80 Muy buena explicación, ¡chapó!
En cuanto a
Javascript -> Redux(sin react) -> React
Como ejemplo, si provienes de Angular y quieres probar React, mejor comprender el funcionamiento del estado de React y luego indagar con Redux, ¿no? Recuerdo que cuando trabajaba con Angular, cuando pasé a React no me entraba en la cabeza como funcionaba el estado 
Una vez que lo entiendes, fluye mucho mejor. Pero vamos, estoy de acuerdo que antes de meterte con esta librería, hay que saber JavaScript bien (y sobre todo saber tratar de forma bonita a los objetos )
Por cierto, como curiosidad en React v17
React v17 is the first version that allows you to use JSX without importing React using preset-env
Voy a empezar a eliminar lineas y lineas de import * as React from 'react' en los tests
Por qué ibas a aprender React antes que Redux si Redux no está atado a React? :/
Me refiero, dices que primero ver como va React antes de mirar Redux, cuando realmente en Angular tambien puedes usar Redux, ya que éste es un concepto orientado a apps JS.
#80JohnVoiden:Esto es incorrecto, el estado es la aplicación y el estilo de programación no afecta porque React tiene una manera de trabajar muy concreta. Que curiosamente es hacía funcional.
Si esto es lo que quería decir exactamente, y lo mismo con redux. Excluyente no es que no depende una del otra? lo he dicho bien no? dos sets que no interseccionan no? xd
#80JohnVoiden:Lo que pasa es que estamos comentando que hacer las maneras diferentes de gestion de estados afecta directamente a su programación y visualización en arquitectura, una app de Redux no tiene nada que ver con una app de Contexts nativos a saco.
(Edit: fijate que arriba dices que afecta y mas arriba dices que no)
Aquí creo que ha habido confusión con el lenguaje. Pero si ahora lo he entendido bien creo que coincidimos:
React+Redux arquitectura: No deberia haber problema, redux con lo que sea no deberias tener problema. Con angular+ngrx yo uso ngrx a veces y otras no y comparto interficie...
React+Redux implementacion: Si tienes razon esta coplado relacion directa.
Y pls de react no quiero comentar que sabeis que no tengo ni idea, he entrado por redux y la fp.
#80JohnVoiden:Cuando esta mal hecho sí.
De nuevo si pero no.
Si completamente de acuerdo porque esta mal hecho, pero eso no es complejidad "intrinsica" de Redux y mi objetivo era transmitir eso. Que no deberia a;adir complejidad sino quitarla si lo haces bien. Pude que te parezca DIFICIL por no saber usarlo (experiencia ) y/o no conocer las bases (teoria), ese es otro tema. Debido a ser dificil para ti lo haces mal. dificil -> creas complejo.
Igual que te puedes matar con una cuchara y una cuchara no puedes decir que es una arma blanca.
#82 Realmente puedes aprender en paralelo. yo si quiero ser web dev primero aprenderia el fw y luego la gestion de estado (que me resolvera problemas con los que me he encontrado). pero no existe una dependencia react -> redux ni redux -> react.
En unos dias revisitare redux que hace meses que no lo toco a ver que le han metido.
#82 Toda la razón, lo comentaba en caso de que se pase de un framework/librería (o desde JS puro) que no se utilizase Redux previamente y una persona quiera saber como funciona React.
Si no, da igual ese orden, pero JavaScript siempre el primero.
Si dificil no es, pero el boiler plate que lleva es un coñazo,y puedes caer en el problema de hacer sobreingenieria y meterlo en lugares donde no toca.
Además que salvo ciertas excepciones tampoco es necesario normalmente.
Cuando lo necesitas y se ejecuta de forma correcta es la bomba.
Estoy viendo la conferencia de ReactRally, y el próximo en hablar es tito Kent C. Dodds. Justamente va a hablar sobre el como controlar el estado de React sin necesidad de Redux o MobX
For the last few years of using React, we as a community have been trying to solve the hard problem of application state management with React when we already had one all along. React itself is a state management library. You can use features and practices that have been a part of React for a long time and it will change the way you think about UI state management for your React apps. In other words: you probably don't need Redux, MobX, or any state management library other than React. Let’s explore how that’s possible and why you might want to think twice before reaching for an abstraction.
Me esta pasando una cosa super rara, tengo un componente que no me estan haciendo trigger ningun hook, ni de inicio:
React.useEffect(() => {
console.log('hi')
}, [])
Tengo algo tal que asi, y no me saca el console log ni en primer render, ni segundo, he probado poniendo dependencias, todo, no hay cojones de que entre.
No tengo ni puta idea de que esta pasando hulio, alguno mas experimentado podria iluminarme de que mierdas me puede estar pasando aqui?
#89 No, eso no es.
Otro ejemplo, que sigue sin funcionar:
React.useEffect(() => {
setCount(count => count++)
}, [count])
Tengo algo asi que me deberia petar por los cielos por infinite re-render y no ocurre absolutamente nada wtf....
