`, `<Avatar>` y `<Subscribe>`. `<Container>` y su familia son muy felices aunque él es un padre estricto. `<Container>` sabe muy bien cómo utilizar `fetch` para adquirir datos desde el servidor, es un componente muy bien conectado y no le representa esfuerzo conseguir recursos para su familia, así ninguno de sus hijos tiene que trabajar para conseguir los recursos que necesitan. `<Avatar />` es creativa y le encantan las imágenes, pero aún es muy pequeña. Mientras que `<Title>` es el mayor de todos, siempre preocupado por quedar bien. `<Subscribe>` es el más inquieto de los tres, es muy extrovertido y le gusta conocer personas nuevas, pero regularmente se mete en problemas. Todos ellos conforman este ejemplo.\n\n![IMG_3176.heic](https://i.morioh.com/201022/2f6459ee.webp)\n\nEl último problema en el que `<Subscribe>` se metió, es que descubrió sus props. Ya le brotó pelo en todo el cuerpo y también descubrió un `<input>` que es parte de su `JSX`. Lo anduvo explorando a pesar de que su papá le dijo que jamás se tocará ahí. Pero buscándole, `<Subscribe>` encontró algunos `props` que puede utilizar: , `value` y `onChange`, pero no sabe cómo usarlos, así que se puso a buscar por internet. \n\n`<Subscribe>` buscó bastante, y encontró mucho ruido sobre estados globales: **Redux**, **Xstate**, **Zustand**, **Jotai** y también encontró mucha paja sobre **Context**. Pero toda esa *info* le parece abrumadora y prefiere simplemente implementar un estado local y jugar con el `onChange`, así que decide preguntarle a su amigo alcohólico: `useState()`. Este amigo, es muy amable, pues le proporciona lo que necesita…\n\n`<Subscribe>` se ve algo así ahora:\n\n```jsx\nexport const Subscribe = () => {\n // estado local:\n const [value, set] = useState(\"\");\n // manejador del estado:\n const handleChange = (e) => set(e.currentTarget.value); // ChangeEvent<HTMLInputElement>\n // uso del estado:\n return <input onChange={handleChange} value={value} />;\n};\n\n```\n\nOk, `<Subscribe>` tiene un estado donde almacenar el texto que el usuario escribe, muy bien. ¿Cómo se los mandamos al servidor?, le pregunta a su amigo sin recibir respuesta.\n\nComo `<Subscribe>` tampoco puede preguntar a sus hermanos, pues en **React** los nodos hermanos no pueden comunicarse. Igual que `<Subscribe>` sus hermanos solo pueden recibir información de sus padres, así que, decide entonces, preguntar a su papá. 👴🏼\n\n`<Container />`, padre de `<Subscribe>`, no tiene problema en crearse un método `sendSubscriber()` y comunicarse con el servidor. El problema se encuentra en que `<Container />` no tiene acceso al estado local de su hijo `<Subscriber />`. Entonces, ¿cómo hacemos para que `<Subscriber />` pueda entregar el correo electrónico del usuario al componente padre `<Container />`? ¿Cómo chingados pasamos el estado?, se preguntó `<Subscriber>` y echó a llorar.\n\n## Intentos chafas\n\nMuy a menudo me toca leer código al que yo llamo: “chafa” o que es muy susceptible a fallos, difícil de mantener y complejo que dificulta el razonamiento sobre el mismo. Este tipo de código representa nuestra forma de pensar 💭 **sin,** el *one-way data flow*. 🍝\n\nEste sería un ejemplo de código chafa:\n\n```jsx\nexport const Subscribe = ({ onChange }) => {\n const [state, set] = useState(\"\"); // esto ya no es necesario?\n const handleChange = (e) => {\n set(e.currentTarget.value); // esto es\n onChange?.(e.currentTarget.value); // muy similar 😒\n };\n return <input onChange={handleChange} value={state} />;\n};\n\n```\n\nParece inofensivo y muy común ¿verdad? Pero hemos agregado un `prop` a nuestro componente, también hemos colocado una llamada opcional a `onChange`. Recibiríamos el valor en el padre, con este pequeño cambio ahora podemos comunicar al padre, pero también estamos repitiendo algo de código y hasta se siente como que aquí hay estados de sobra… ¿Apoco no? 👎\n\nLo peor es que, con todo esto que agregamos, ahora el padre necesita un estado también. 😅\n\n```jsx\nexport const Container = () => {\n const [inputValue, setInputValue] = useState(\"\");\n return <Subscribe onChange={(value) => setInputValue(value)} />;\n};\n\n```\n\n¡Pero espérate! Que tengo otros ejemplos de código chafa. Como este que agrega asincronía y efectos secundarios a nuestro ejemplo, para que la cabeza duela en serio. 🤕\n\n```jsx\nexport const Subscribe = ({ onChange, value }) => {\n // estado local:\n const [state, set] = useState(value); // esto es mejor con defaultValues 🚫\n // manejador del estado:\n const handleChange = (e) => {\n set(e.currentTarget.value);\n };\n\n useEffect(() => {\n onChange?.(state);\n }, [state, onChange]); // esto es peligroso ⚠️\n\n // uso del estado:\n return <input onChange={handleChange} value={value || state} />;\n};\n\n```\n\nSeguro que has visto código así; no lo haga compa. 👩🏾‍🌾 \n\nEsto se puede resolver de una manera simple, volvamos a nuestra historia y veamos cómo.\n\n## Salvemos el día con el One-way data flow\n\nDespués de presentar todas estas opciones, `<Subscribe>` guardó silencio y permitió que su padre, que ya era un *senior*, le explicara **qué es el One-way data flow:**\n\nEn todos los casos, **se trata de subir el estado un nivel, al padre** y también de que solo el padre posea los estados necesarios y lo más importante: que **solo el padre los pueda cambiar**. 👨🏻‍🔧\n\nSus hijos, solo recibirán `props` y composición. ✅ \n\n> 👀 No me refiero a estados locales de componente, como booleanos para tabs o índices, o *switches*, me refiero a **estados que almacenan datos relacionados al usuario**, como su correo. 📦 Aprende más sobre composición [aquí](https://fixtergeek.com/blog/3-reglas-que-debes-recordar-para-crear-componentes-react-realmente-reutilizables-2023).\n> \n\n```jsx\nexport const Container = () => {\n const [email, setEmail] = useState(\"\"); // El padre es el dueño del único estado\n\n const sendSubscriberToServer = () => {\n fetch(\"/subs\", { body: { email }, method: \"post\" }); // Simplificado 👶🏻\n };\n return <Subscribe value={email} onChange={(value) => setEmail(value)} />;\n};\n\n// Subscribe.tsx\nexport const Subscribe = ({ onChange, value }) => {\n // Input controlado, La mutación sucede en niveles superiores\n return <input onChange={onChange} value={value} />;\n};\n\n```\n\nSu padre le explicó de dos maneras, primero la más común y que la mayoría de los developers **React** profesionales usa: **escuchando cada uno de los cambios en el input**. A esto se le conoce como componentes controlados. Ahora que el estado le pertenece al padre y solo al padre, **ninguno** **de sus hijos es responsable de conseguir o mantener recursos**, solo el padre. 🧔🏻‍♂️💵\n\nAsí que, si alguno de sus hijos tiene que reaccionar al usuario, como con un `onChange`, lo único que necesita saber es cuál es el `prop` a usar. En este caso cualquier función dentro de `onChange`. \n\n`<Subscribe>` puede enviar el *email* a su padre con su *prop* `onChange` en cada momento. No necesita saber nada más, nada sobre la vida mafiosa de su padre, 🔫 ni enterarse de que los recursos que consigue están bañados en sangre… 🩸🧧\n\n> 👀 Este era el típico demo de **React** que veías en todas partes antes del 2020 (`onChange`). Siempre me pareció mucho trabajo 🤖 para formularios grandes. Te voy a enseñar una manera mejor. 😉\n> \n\n## ¿Cómo lo haríamos con flujo de datos unidireccional?\n\nLa segunda forma que le mostró su padre, es la favorita del autor. ✍🏼\n\nSe trata de pensar menos en **JS** y más en **HTML**. 🤯\n\n```jsx\nexport const Container = () => {\n\tconst inputRef = useRef();\n\tconst sendSubscriberToServer = (event) => {\n\t\t// ...\n\t\tfetch('/subs', {body:{inputRef.current.value}, method:'post'});\n\t}\n\treturn ( <Subscribe ref={ref} name=\"email\" />);\n} \n\n// Subscribe.tsx\nexport const Subscribe = forwardRef(({...props}, ref)=>{\n\treturn <input {...props} ref={ref} /> \n})\n```\n\nLo primero que debes observar aquí, es que `<Subscribe>` ahora es *display*, nada de manejar su propio estado, **ni siquiera tiene que usar props**, solo pasar una referencia (`useRef`). 🤯\n\nCon esto, puedes armar todo el <form> como un *display* y tener todos los datos en el `ref`.\n\n¡Pero claro, esto también se puede hacer de manera más tradicional! 👘\n\nSi no te gustan los `forwardRef`, hagámoslo interceptando el `onSubmit` por ejemplo:\n\n```jsx\nexport const Container = () => {\n const sendSubscriberToServer = (event) => {\n event.preventDefault(); // evitamos el *refresh* de la página\n // ...\n fetch(\"/subs\", {\n body: { email: event.currentTarget.name.value },\n method: \"post\",\n });\n };\n return (\n <form onSubmit={sendSubscriberToServer}>\n <Subscribe />\n </form>\n );\n};\n\n// Subscribe.tsx\nexport const Subscribe = () => <input name=\"email\" type=\"email\" />;\n// esto es *presentational* incluso siendo un input\n\n```\n\nAquí estamos echando mando de nuestra vieja amiga, la etiqueta `<form>` que nos ayudará a sacarle el valor a `<Subscribe>` gracias al evento `onSubmit`. 🫧\n\nPodríamos mudar la etiqueta `<form>` dentro de `<Subscribe>`, pero así es mejor, **podemos componer el formulario** con más *inputs* reutilizables, *dumb* y *presentational* o de *display* (*Display Components*).\n\n> 👀 Yo prefiero llamarle **Componentes de display** o solo “*display*”. Y a veces erróneamente les llamo *dummys*. 😅\n> \n\nTodo esto se complementa de forma maravillosa, cuando agregas composición. Manteniendo el manejo del estado en un solo nivel y utilizando componentes de *display*, **componentes que solo representan sus props**. Es como meter tu mano en un guante de lana suave y que se ajusta perfectamente a la forma de tus nudillos, ahora te pones el otro...\n\nEs hora del último ejemplo y ver si todo esto ahora te hace mirar un poco diferente: 👽\n\n```jsx\nexport default function OtroEjemplo() {\n const { members, user, mutateMember } = useQueryService(); // cualquier query lib\n // Es bonito utilizar los datos de tu modelo directamente (Partial<TuModelo>)\n\n const reducerToHandleAllActions = (action) => {\n // switch... mutateMember(action.payload)\n };\n\n return (\n <Layout user={user}>\n <Table theme={user.theme} items={members}>\n {(member) => (\n <Row\n member={member}\n highlight={member.isVip}\n actions={\n <Actions\n onAction={reducerToHandleAllActions}\n ability={user.ability}\n extraActions={[\n <TestingActions\n onAction={reducerToHandleAllActions}\n member={member}\n />,\n ]}\n render={(allActions) => (\n <BasicActions extraActions={allActions} />\n )}\n />\n }\n />\n )}\n </Table>\n <PersonalOffer membershipType={user.membership?.type} />\n <Alerts isEveryMemberConfirmed={members.every((m) => m.confirmed)} />\n </Layout>\n );\n}\n\n```\n\nMi intención no es confundirte con este código, si no que puedas ver este grupo de componentes ya no solo como **JSX** y `props`. Si no, como componentes que se emplean de forma eficiente, porque **utilizan un flujo de datos de una sola dirección** explotando la composición para este fin. Pero lo más importante y lo que quiero que te lleves, es que: \n\n**solo su padre maneja el estado de todos los componentes en un solo lugar**. ✅ 😎\n\n¿Maravilloso no? 🤓\n\n### Ahora ya sabes a qué nos referimos cuando hablamos del One-way data flow.\n\n**Tiene más que ver con mantener el estado (y sus mutaciones) en un solo nivel**. ✅\n\nEstos ejemplos están extremadamente simplificados a propósito y con fines educativos. Estoy dejando por fuera muchos más conceptos, como cuando se trata de una tabla **CRUD,** por ejemplo. ¿Cómo sería esa comunicación? si este contenido te parece útil, no dejes de compartirlo con tus amigos. Así me motivo para crear más contenido relacionado y complementar este.\n\nNos leemos en el siguiente. Abrazo. Bliss. 🤓\n\n## Enlaces relacionados\n\n[Aprende más sobre composición](https://fixtergeek.com/blog/3-reglas-que-debes-recordar-para-crear-componentes-react-realmente-reutilizables-2023)\n\n[Descubre qué es **HTMX** y el **Hyper-Media System**](https://htmx.org/essays/is-htmx-another-javascript-framework/?ck_subscriber_id=1950118074)\n\n[Pensando en React](https://react.dev/learn/thinking-in-react)","authorAt","@hectorbliss","photoUrl","https://i.imgur.com/TaDTihr.png","isFeatured",false,"metaImage","youtubeLink","","authorAtLink","https://twitter.com/HectorBlisS","authorName","Héctorbliss","mainTag","React","tags",[46,47,48,49,50],"hooks","functions","data","principios","fundamentos","category",[53,54,55],"js","front-end","webdev","posts",[],"audioData","root","actionData","errors"] </article></body></html>

[{"_1":2,"_60":-5,"_61":-5},"loaderData",{"_3":4,"_59":-5},"routes/post",{"_5":6,"_56":57,"_58":-5},"post",{"_7":8,"_13":14,"_15":16,"_17":18,"_19":20,"_21":22,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34,"_35":26,"_36":37,"_38":39,"_40":41,"_42":43,"_44":45,"_51":52},"banner",{"_9":10,"_11":12},"img","/assets/courses/banner_minimojs.png","link","/courses/minimo-js-para-react/detail","id","6400d254ef45c3b7f21c7588","createdAt",["D",1677775444090],"updatedAt",["D",1705785634531],"slug","flujo-de-datos-unidireccional-one-way-data-flow-2024","title","Flujo de datos unidireccional (one-way data flow)","published",true,"coverImage","https://i.imgur.com/RO9PAmw.png","body","# ¿Qué es One-Way data flow en React?\n\nNop, no tiene que ver con el **flow** **bellacoso** que te hace “perrar” hasta el piso. 👯‍♀️🪩 No. 👨🏼‍🎤\n\n![bellacoso](https://i.ytimg.com/vi/oNv6_RXS0dc/maxresdefault.jpg)\n\nEs más una forma de diseñar jerarquías de nodos o árboles de componentes en **React** y sobre la comunicación entre ellos, se trata más de **limitar el flujo y la mutación de los datos** que vienen del servidor en un solo nivel, el del padre. 👨🏻\n\n> ¿Se es inclusivo si se dijese: “El estado debe vivir en el componente madre” 🤔\n> \n\nHace un par de años, yo no terminaba de entender este concepto, era tan obvio que no me hacía sentido, no lograba entender por qué era importante. Claro, le pasamos `props` a los componentes hijos, ahí está, eso es el *one-way data flow* ¿no? \n\nPero ahora, después de mucho código de principiante y de escribir muchísimos componentes que nomás no hayan por donde comunicarse con su padre (como tu amiga, que se quedó esperando que su papá volviera de comprar cigarros 🚬). \n\nHoy en día mis componentes favoritos son los componentes “*dumb*” o “*presentacionales*” **que no tienen por qué estar al pendiente de nada**, solo de mostrar sus `props` (datos) más frescos. \n**Deben ser como televisiones** que reciben los datos de la señal, los interpretan y los muestran, nunca los modifican. 📺 👀 Fíjate, las TV también tienen un estado interno y local (el canal actual y la cantidad de canales) y eso no lo ponen en un estado global en Redux **¿verdad juanito? 😫**\n\nEn esta entrada, me dispongo a explicarte por qué pienso que el **OWDF** (*One-way data flow*) se trata más de una forma de pensar y un patrón de diseño, que solo pasar `props`. \n\nJusto por eso hoy en día la documentación de **React** toca este tema con el titulo: “[pensando en React](https://react.dev/learn/thinking-in-react)”. 🧠\n\nVamos a ver si te puedo ayudar a visualizar mejor. 🤓 🖼️\n\n## Pensando en React\n\nImaginemos un árbol de componentes de solo 2 niveles. Un padre `` y tres pequeños y saludables hijitos: ``, `<Avatar>` y `<Subscribe>`. `<Container>` y su familia son muy felices aunque él es un padre estricto. `<Container>` sabe muy bien cómo utilizar `fetch` para adquirir datos desde el servidor, es un componente muy bien conectado y no le representa esfuerzo conseguir recursos para su familia, así ninguno de sus hijos tiene que trabajar para conseguir los recursos que necesitan. `<Avatar />` es creativa y le encantan las imágenes, pero aún es muy pequeña. Mientras que `<Title>` es el mayor de todos, siempre preocupado por quedar bien. `<Subscribe>` es el más inquieto de los tres, es muy extrovertido y le gusta conocer personas nuevas, pero regularmente se mete en problemas. Todos ellos conforman este ejemplo.\n\n![IMG_3176.heic](https://i.morioh.com/201022/2f6459ee.webp)\n\nEl último problema en el que `<Subscribe>` se metió, es que descubrió sus props. Ya le brotó pelo en todo el cuerpo y también descubrió un `<input>` que es parte de su `JSX`. Lo anduvo explorando a pesar de que su papá le dijo que jamás se tocará ahí. Pero buscándole, `<Subscribe>` encontró algunos `props` que puede utilizar: , `value` y `onChange`, pero no sabe cómo usarlos, así que se puso a buscar por internet. \n\n`<Subscribe>` buscó bastante, y encontró mucho ruido sobre estados globales: **Redux**, **Xstate**, **Zustand**, **Jotai** y también encontró mucha paja sobre **Context**. Pero toda esa *info* le parece abrumadora y prefiere simplemente implementar un estado local y jugar con el `onChange`, así que decide preguntarle a su amigo alcohólico: `useState()`. Este amigo, es muy amable, pues le proporciona lo que necesita…\n\n`<Subscribe>` se ve algo así ahora:\n\n```jsx\nexport const Subscribe = () => {\n // estado local:\n const [value, set] = useState(\"\");\n // manejador del estado:\n const handleChange = (e) => set(e.currentTarget.value); // ChangeEvent<HTMLInputElement>\n // uso del estado:\n return <input onChange={handleChange} value={value} />;\n};\n\n```\n\nOk, `<Subscribe>` tiene un estado donde almacenar el texto que el usuario escribe, muy bien. ¿Cómo se los mandamos al servidor?, le pregunta a su amigo sin recibir respuesta.\n\nComo `<Subscribe>` tampoco puede preguntar a sus hermanos, pues en **React** los nodos hermanos no pueden comunicarse. Igual que `<Subscribe>` sus hermanos solo pueden recibir información de sus padres, así que, decide entonces, preguntar a su papá. 👴🏼\n\n`<Container />`, padre de `<Subscribe>`, no tiene problema en crearse un método `sendSubscriber()` y comunicarse con el servidor. El problema se encuentra en que `<Container />` no tiene acceso al estado local de su hijo `<Subscriber />`. Entonces, ¿cómo hacemos para que `<Subscriber />` pueda entregar el correo electrónico del usuario al componente padre `<Container />`? ¿Cómo chingados pasamos el estado?, se preguntó `<Subscriber>` y echó a llorar.\n\n## Intentos chafas\n\nMuy a menudo me toca leer código al que yo llamo: “chafa” o que es muy susceptible a fallos, difícil de mantener y complejo que dificulta el razonamiento sobre el mismo. Este tipo de código representa nuestra forma de pensar 💭 **sin,** el *one-way data flow*. 🍝\n\nEste sería un ejemplo de código chafa:\n\n```jsx\nexport const Subscribe = ({ onChange }) => {\n const [state, set] = useState(\"\"); // esto ya no es necesario?\n const handleChange = (e) => {\n set(e.currentTarget.value); // esto es\n onChange?.(e.currentTarget.value); // muy similar 😒\n };\n return <input onChange={handleChange} value={state} />;\n};\n\n```\n\nParece inofensivo y muy común ¿verdad? Pero hemos agregado un `prop` a nuestro componente, también hemos colocado una llamada opcional a `onChange`. Recibiríamos el valor en el padre, con este pequeño cambio ahora podemos comunicar al padre, pero también estamos repitiendo algo de código y hasta se siente como que aquí hay estados de sobra… ¿Apoco no? 👎\n\nLo peor es que, con todo esto que agregamos, ahora el padre necesita un estado también. 😅\n\n```jsx\nexport const Container = () => {\n const [inputValue, setInputValue] = useState(\"\");\n return <Subscribe onChange={(value) => setInputValue(value)} />;\n};\n\n```\n\n¡Pero espérate! Que tengo otros ejemplos de código chafa. Como este que agrega asincronía y efectos secundarios a nuestro ejemplo, para que la cabeza duela en serio. 🤕\n\n```jsx\nexport const Subscribe = ({ onChange, value }) => {\n // estado local:\n const [state, set] = useState(value); // esto es mejor con defaultValues 🚫\n // manejador del estado:\n const handleChange = (e) => {\n set(e.currentTarget.value);\n };\n\n useEffect(() => {\n onChange?.(state);\n }, [state, onChange]); // esto es peligroso ⚠️\n\n // uso del estado:\n return <input onChange={handleChange} value={value || state} />;\n};\n\n```\n\nSeguro que has visto código así; no lo haga compa. 👩🏾‍🌾 \n\nEsto se puede resolver de una manera simple, volvamos a nuestra historia y veamos cómo.\n\n## Salvemos el día con el One-way data flow\n\nDespués de presentar todas estas opciones, `<Subscribe>` guardó silencio y permitió que su padre, que ya era un *senior*, le explicara **qué es el One-way data flow:**\n\nEn todos los casos, **se trata de subir el estado un nivel, al padre** y también de que solo el padre posea los estados necesarios y lo más importante: que **solo el padre los pueda cambiar**. 👨🏻‍🔧\n\nSus hijos, solo recibirán `props` y composición. ✅ \n\n> 👀 No me refiero a estados locales de componente, como booleanos para tabs o índices, o *switches*, me refiero a **estados que almacenan datos relacionados al usuario**, como su correo. 📦 Aprende más sobre composición [aquí](https://fixtergeek.com/blog/3-reglas-que-debes-recordar-para-crear-componentes-react-realmente-reutilizables-2023).\n> \n\n```jsx\nexport const Container = () => {\n const [email, setEmail] = useState(\"\"); // El padre es el dueño del único estado\n\n const sendSubscriberToServer = () => {\n fetch(\"/subs\", { body: { email }, method: \"post\" }); // Simplificado 👶🏻\n };\n return <Subscribe value={email} onChange={(value) => setEmail(value)} />;\n};\n\n// Subscribe.tsx\nexport const Subscribe = ({ onChange, value }) => {\n // Input controlado, La mutación sucede en niveles superiores\n return <input onChange={onChange} value={value} />;\n};\n\n```\n\nSu padre le explicó de dos maneras, primero la más común y que la mayoría de los developers **React** profesionales usa: **escuchando cada uno de los cambios en el input**. A esto se le conoce como componentes controlados. Ahora que el estado le pertenece al padre y solo al padre, **ninguno** **de sus hijos es responsable de conseguir o mantener recursos**, solo el padre. 🧔🏻‍♂️💵\n\nAsí que, si alguno de sus hijos tiene que reaccionar al usuario, como con un `onChange`, lo único que necesita saber es cuál es el `prop` a usar. En este caso cualquier función dentro de `onChange`. \n\n`<Subscribe>` puede enviar el *email* a su padre con su *prop* `onChange` en cada momento. No necesita saber nada más, nada sobre la vida mafiosa de su padre, 🔫 ni enterarse de que los recursos que consigue están bañados en sangre… 🩸🧧\n\n> 👀 Este era el típico demo de **React** que veías en todas partes antes del 2020 (`onChange`). Siempre me pareció mucho trabajo 🤖 para formularios grandes. Te voy a enseñar una manera mejor. 😉\n> \n\n## ¿Cómo lo haríamos con flujo de datos unidireccional?\n\nLa segunda forma que le mostró su padre, es la favorita del autor. ✍🏼\n\nSe trata de pensar menos en **JS** y más en **HTML**. 🤯\n\n```jsx\nexport const Container = () => {\n\tconst inputRef = useRef();\n\tconst sendSubscriberToServer = (event) => {\n\t\t// ...\n\t\tfetch('/subs', {body:{inputRef.current.value}, method:'post'});\n\t}\n\treturn ( <Subscribe ref={ref} name=\"email\" />);\n} \n\n// Subscribe.tsx\nexport const Subscribe = forwardRef(({...props}, ref)=>{\n\treturn <input {...props} ref={ref} /> \n})\n```\n\nLo primero que debes observar aquí, es que `<Subscribe>` ahora es *display*, nada de manejar su propio estado, **ni siquiera tiene que usar props**, solo pasar una referencia (`useRef`). 🤯\n\nCon esto, puedes armar todo el <form> como un *display* y tener todos los datos en el `ref`.\n\n¡Pero claro, esto también se puede hacer de manera más tradicional! 👘\n\nSi no te gustan los `forwardRef`, hagámoslo interceptando el `onSubmit` por ejemplo:\n\n```jsx\nexport const Container = () => {\n const sendSubscriberToServer = (event) => {\n event.preventDefault(); // evitamos el *refresh* de la página\n // ...\n fetch(\"/subs\", {\n body: { email: event.currentTarget.name.value },\n method: \"post\",\n });\n };\n return (\n <form onSubmit={sendSubscriberToServer}>\n <Subscribe />\n </form>\n );\n};\n\n// Subscribe.tsx\nexport const Subscribe = () => <input name=\"email\" type=\"email\" />;\n// esto es *presentational* incluso siendo un input\n\n```\n\nAquí estamos echando mando de nuestra vieja amiga, la etiqueta `<form>` que nos ayudará a sacarle el valor a `<Subscribe>` gracias al evento `onSubmit`. 🫧\n\nPodríamos mudar la etiqueta `<form>` dentro de `<Subscribe>`, pero así es mejor, **podemos componer el formulario** con más *inputs* reutilizables, *dumb* y *presentational* o de *display* (*Display Components*).\n\n> 👀 Yo prefiero llamarle **Componentes de display** o solo “*display*”. Y a veces erróneamente les llamo *dummys*. 😅\n> \n\nTodo esto se complementa de forma maravillosa, cuando agregas composición. Manteniendo el manejo del estado en un solo nivel y utilizando componentes de *display*, **componentes que solo representan sus props**. Es como meter tu mano en un guante de lana suave y que se ajusta perfectamente a la forma de tus nudillos, ahora te pones el otro...\n\nEs hora del último ejemplo y ver si todo esto ahora te hace mirar un poco diferente: 👽\n\n```jsx\nexport default function OtroEjemplo() {\n const { members, user, mutateMember } = useQueryService(); // cualquier query lib\n // Es bonito utilizar los datos de tu modelo directamente (Partial<TuModelo>)\n\n const reducerToHandleAllActions = (action) => {\n // switch... mutateMember(action.payload)\n };\n\n return (\n <Layout user={user}>\n <Table theme={user.theme} items={members}>\n {(member) => (\n <Row\n member={member}\n highlight={member.isVip}\n actions={\n <Actions\n onAction={reducerToHandleAllActions}\n ability={user.ability}\n extraActions={[\n <TestingActions\n onAction={reducerToHandleAllActions}\n member={member}\n />,\n ]}\n render={(allActions) => (\n <BasicActions extraActions={allActions} />\n )}\n />\n }\n />\n )}\n </Table>\n <PersonalOffer membershipType={user.membership?.type} />\n <Alerts isEveryMemberConfirmed={members.every((m) => m.confirmed)} />\n </Layout>\n );\n}\n\n```\n\nMi intención no es confundirte con este código, si no que puedas ver este grupo de componentes ya no solo como **JSX** y `props`. Si no, como componentes que se emplean de forma eficiente, porque **utilizan un flujo de datos de una sola dirección** explotando la composición para este fin. Pero lo más importante y lo que quiero que te lleves, es que: \n\n**solo su padre maneja el estado de todos los componentes en un solo lugar**. ✅ 😎\n\n¿Maravilloso no? 🤓\n\n### Ahora ya sabes a qué nos referimos cuando hablamos del One-way data flow.\n\n**Tiene más que ver con mantener el estado (y sus mutaciones) en un solo nivel**. ✅\n\nEstos ejemplos están extremadamente simplificados a propósito y con fines educativos. Estoy dejando por fuera muchos más conceptos, como cuando se trata de una tabla **CRUD,** por ejemplo. ¿Cómo sería esa comunicación? si este contenido te parece útil, no dejes de compartirlo con tus amigos. Así me motivo para crear más contenido relacionado y complementar este.\n\nNos leemos en el siguiente. Abrazo. Bliss. 🤓\n\n## Enlaces relacionados\n\n[Aprende más sobre composición](https://fixtergeek.com/blog/3-reglas-que-debes-recordar-para-crear-componentes-react-realmente-reutilizables-2023)\n\n[Descubre qué es **HTMX** y el **Hyper-Media System**](https://htmx.org/essays/is-htmx-another-javascript-framework/?ck_subscriber_id=1950118074)\n\n[Pensando en React](https://react.dev/learn/thinking-in-react)","authorAt","@hectorbliss","photoUrl","https://i.imgur.com/TaDTihr.png","isFeatured",false,"metaImage","youtubeLink","","authorAtLink","https://twitter.com/HectorBlisS","authorName","Héctorbliss","mainTag","React","tags",[46,47,48,49,50],"hooks","functions","data","principios","fundamentos","category",[53,54,55],"js","front-end","webdev","posts",[],"audioData","root","actionData","errors"] </article></body></html>

Flujo de datos unidireccional (one-way data flow)

Héctorbliss

Escuchar este post

Animaciones web con React + Motion 🧙🏻