Aquí hablan del tema: https://benlesh.com/posts/tc39-pipeline-proposal-hack-vs-f-sharp/
A mi la opción de f# me parece bastante mejor, pero ellos sabrán.
Aquí hablan del tema: https://benlesh.com/posts/tc39-pipeline-proposal-hack-vs-f-sharp/
A mi la opción de f# me parece bastante mejor, pero ellos sabrán.
Comparto la enesima libreria de gestion de estados, no la conocia, pero parece ser bastante popular y la api mola mucho, me gustaria probarla en un futuro:
https://github.com/pmndrs/zustand
La verdad es que tiene una pinta tremenda
#633 Que la api mola? Que uses la misma declaración solo cambiando el tipo de parametro me da mal rollo. Para cambiar totalmente el objetivo del hook. HELL NO
import create from 'zustand'
const useStore = create(set => ({
bears: 0,
increasePopulation: () => set(state => ({ bears: state.bears + 1 })),
removeAllBears: () => set({ bears: 0 })
}))
function BearCounter() {
const bears = useStore(state => state.bears)
return <h1>{bears} around here ...</h1>
}
function Controls() {
const increasePopulation = useStore(state => state.increasePopulation)
return <button onClick={increasePopulation}>one up</button>
}
Lo siento, pero no, eso me da escalofríos porque la gente no sabrá usarlo y estará igual que con useState creando 10 useStates por componente.
#634 No entiendo tu problema.
Si la gente no sabe hacer
const { var1, var2 } = useStore( state => ({ var1: state.var1, var2: state.var2 }) )
Es problema de los monos de tu equipo, no de la api de la libreria.
#635 Será por la mañana y no me habré explicado bien.
Cuando creas useStore con zustand, la declaras todo perfecto.
Pero cuando quieres acceder a 2 tipos de cosas diferentes dentro del store, además que no es estado únicamente,si no son acciones y estado. Solo lo cambias por su manera de llamarlo:
state => state.increasePopulation
o
state => state.bears
2 lineas de codigo que son 1 estado y 1 acción. Solo lo sabes por el nombre, pero nada más porque zustand te hace agnostica la logica de modificacion de estado de 'increasePopulation' con su filosofia de libreria.
A mi eso me parecen 2 cosas:
1 - Tendrás que ir revisando que la acción dentro de tu "microstore". Si no confias tu codigo ciegamente.
2 - No se que diferencia tiene en hacer un useReducer, no le veo ningun tipo de beneficio. Prefiero que los programadores(monos) de mi equipo sepan utilizar apis de la libreria(reactjs) que librerias randoms xd
Respecto lo que comentas del destructuring:
Estoy leyendo su documentación y es para cuando tienes un estado con multiples valores, solo te interesa coger uno para que no haya updates innecesarios.
Siento que estas librerías no aportan nada, son capas sobre capas.
#636 Tu punto 2 me parece correcto, y yo lo he pensado tambien.
El resto estoy en deacuerdo parcialemente.
Primero, el naming, step = estado, setStep => modificas estado.
Segundo, TypeScript, te dice que lo que le estas pasando al boton es un string y no un arrow function.
Para mi, por tanto, no es problema de uso del store, si no de declaracion cuando lo creas, con estados complejos puedes acabar con un create de 500 lineas, ahi optaria por organizacion por carpetitas y ficheros e importar al create por separado (Ya """desacoplas"" al menos a nivel visual/ide).
Luego, tema acomplamiento, cierto, es, no se como escalaria en una app muy grande, pero me da la sensacion de que el tema de acomplamiento en React, o "reactivas" es un problema seguro en el tiempo uses lo que uses (Redux, Context...) al final, acabas con cajones de sastre,
Y evidentemente, para orgs grandes, o proyectos en el tiempo, te interesa usar un state management que la gente ya domine (Redux) y sepas que es bulletproof y mantenido en el tiempo. Pero para alguien como yo por ejemplo, proyectos personales o whatever, pues una api tan sencilla a priori, sin el boilerplate de Redux (Ni toolkit) y encima con las ventajas de que actualizar el store no quiere decir actualizar todo el arbol, para mi es un win win win.
#633 A mi de esta misma gente me gusta esta de estado: https://github.com/pmndrs/jotai
Es tipo recoil.js.
Edit: Ya que estamos comparto algo más de esta org:
Para ver como va la libreria estos videos son bastante ilustrativos: https://egghead.io/courses/manage-application-state-with-jotai-atoms-2c3a29f0
Otra libreria guay: react-three-fiber. Wrapper de threejs en react usando react-reconciler (no hay nada hardcoded, es solo el renderer): https://github.com/pmndrs/react-three-fiber (aparte tienen varias librerias relacionadas con 3D usando react).
Han sacado la version 1.0.0 de SWR:
https://swr.vercel.app/blog/swr-v1
Mejor hook de data fetching del ecosistema de React, discutidmelo
#640 Nosotros en la empresa usamos React query y estamos bastante contentos.
#624 Llevo poco utilizando React y la verdad es que me ha gustado leerte porque son cosas que suelo hacer.
El tema del useReducer sí que lo he pensado en cuanto lo he visto. Imagino que tú habrías preferido un reducer y que el estado fuera un objeto con las propiedades que tanto usa aquí tu compi y luego modificarlo con dispatch. Más mantenible, más sencillo.
Lo que no te he entendido es lo de las llamadas a la API. Cómo lo habrías hecho tú? Con un custom hook o a qué te refieres exactamente?
Me encanta leeros porque me doy cuenta del largo (y emocionante) camino que me queda para ser un buen dev.
#644 con las llamadas de la api me refiero a usar Axios a pelo en algun componente tal que así
Minimamente crearia un archivo que se llame PaypalOrderService que exponga una funcion cancelOrder() y asi en mi component solo tengo que llamar a PaypalOrderService.cancelOrder()
#645 si, también habia pensado algo así.
Es que al final te das cuenta de que lo importante es que sea escalable.
Una consulta. Estoy usando Redux para el estado y me surge una duda.
Cuál es el sitio correcto para efectuar un post? En el sentido de:
Habia pensado en un useEffect que en la primera vez no haga nada pero que luego sí lo haga poniendo en las dependencias el objeto que cambia.
¿Cómo lo haríais vosotros?
#647 No he usado Redux, pero creo que lo que estas buscando es un Thunk
https://redux.js.org/tutorials/essentials/part-5-async-logic
#647 Depende, te primeras te diria que los post los suelen lanzar los usuarios. Ejemplo, se cambian su nombre de perfil haciendo submit de un form. Y accion directa de un evento lanzado por el usuario no deberia estar """nunca""" en un useEffect.
Si tu caso es un post que responde a una accion directa del usuario quizas lo estas planteando al reves.
Es decir, lo que yo haria es, el usuario cambia su nombre -> haces un post, responde con 200 la api -> haces un get, recuperas el objeto actualizado y actualizas redux.
Evidentemente esto no es una regla de oro (Y puedes ahorrarte el get), y hay mil casos particulares, pero normalmente suele ser raro tener posts en useEffects.
Osea, lo que quiero decir, es que "normalmente" primeros harias el post (Mediante onSubmit, onClick) y si este es 200 entonces es cuando actualizas redux, de tal forma que nunca necesitarias un useEffect.
Hay casos especiales, ejemplo, logging de eventos y cosas asi, que si que tienen sentido un post en un useEffect o en un listener.
Estoy haciendo un poco de React. Por que esto? No se explicar la duda muy bien, voy a suponer que la gente que domina entendera el problema y el porque.
Este tira error de linter porque no le estoy pasando staticVariable al hook...
const staticVariable = 10;
useEffect(() => {
console.log(staticVariable);
});
Si hago esto:
const staticVariable = 10;
useEffect(() => {
console.log(staticVariable);
}, [staticVariable]);
en mi caso concreto, se quedaba pillado y recargaba constantemente las componentes, peta
y he tenido que hacer esto
const [staticVariable] = useState<Number>(10);
useEffect(() => {
console.log(staticVariable);
}, [staticVariable]);
y asi si funciona bien y el linter no se queja.
Quiero hacer la primera, entiendo que salte el linter por si la lias pero en este caso daba igual porque no tenia componentes por debajo para propagar... Asique es el linter que no esta analizando bien el codigo XD
Hacer 3 tiene algun sobre coste respecto a 1? No deberia preocuparme? Lo he resuelto mal?
Tansolo quiero una variable estatica/immutable que no va a cambiar en la calusura de hook.
#650 Buenos dias, por partes.
const staticVariable = 10;
useEffect(() => {
console.log(staticVariable);
});
Un useEffect sin dependencias (segundo parametro) se lanzara despues de cada ciclo de re-renderizado .
Un useEffect con dependencias vacias (array vacio) solo se lanzara la primera vez que se renderiza el componente.
const staticVariable = 10;
useEffect(() => {
console.log(staticVariable);
}, [staticVariable]);
Aqui dices que se quedaba en bucle, y a riesgo de estar equivocado, te diria que es imposible y que el problema no lo tenias aqui
Pues staticVariable almacena un valor y el valor no cambia nunca entre ciclos, por lo tanto el useEffect no se lanzaria mas que una vez. Ergo, el problema lo tienes en otro lado.
Y respondiendo a tu pregunta:
Tansolo quiero una variable estatica/immutable que no va a cambiar en la calusura de hook.
Para estos casos yo te recomiendo el hook useRef, aun que el useState tampoco esta mal tirado.
#651 Hay otro parametro en el hook que se va haciendo update. Asique si renderiza.
Lo que yo trataba de obtener es que en estos re-renderizados no me recalculase el valor de staticVariable, porque es costoso de obtener. staticVariable checkea las propiedades de tu browser/user-agent y configura unos campos para realizar peticiones.
Voy a mirar de usar el useRef. Gracias, estuve buscando "hooks" pero no lo encontre en la docu... Ahora ya si lo he encontrado lo que buscaba. https://es.reactjs.org/docs/hooks-reference.html esto me servira.
Llevo 2h haciendo React, ni me he leido la docu entera XD
#654 Si, esto no lo sabia ahora me queda claro. El tema es que en mi ejemplo tengo otra variable que si es mutable y se renderiza.
Con lo que me ha respondido ya tengo para seguir.
Es que la docu del linter te hablaba de propagacion, no de renderizado. Pero ahora ya entiendo que el fallo era el wording del lint y por eso no lo entendi bien... Ahora ya entiendi bien lo que pasa.
#655 te explicas como un libro cerrado desu pues
Si la variable es costosa lo que tienes que usar es un useMemo para memoizar el valor.
#650 Sin saber React, te diría de que el segundo caso es porque la constante no es reactiva y en la tercera al hacer el useState sí. Vamos que a useEffect tienes que pasarle attributos observables.
No sería mas facil hacer un jsFiddle y demostrar los distintos casos para ver que no es problema de algo adicional que no estás explicando?
#656 pero si uso el useMemo, igualmente tendre que usar la referencia en el useEffect, no seria el mismo problema?
segun la docu oficial
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
ahora si quiero pasar el memoizedValue tengo el mismo problema, el useMemo para este caso no es necesario si ya tengo el valor en la componente/hook en el top, si necesito propagar ya lo hago... useMemo lo usarias si no quisieras propagar o tuvieses algo como stores/servicio centralizado donde hace las requests de tus componentes...
#657 ah puede ser si, no recuerdo el error que me daba, lo voy a mirar, quizas era un unwrap cuando fixea los hooks... thx lo checkeo
#659 uff muy complicado para mi eso, podria pero no tengo tiempo... una componente tiene un form, cuando cambia el valor se llama el useEffect ese. un parametro es el valor que cambia y el otro es el que quiero estatico.
sin saber react, usar un useEffect para esto no esta mal? lo veo marronero no? useEffect deberia ser solo para side effects.. si estas en el paradigma funcional reactivo claro.