#155 Y cuando quieres iterar tiras de un object.keys ?
No es mala idea, asi en caliente no se me ocurren demasiados pitfalls
#156 Object.keys o los métodos nativos de los diccionarios
Dado que estamos en el hilo de React, un cambio importante sería el caso de una eliminación o modificación.
Un reemplazo o eliminación en un diccionario no cambia la referencia del objeto. Si hay un componente de react que lo recibe como props, no desencadena ciclo de "re-rendeo"
#154 Depende, ¿ para que necesitas los datos ?
Hay estructuras para muchas cosas, todas dependen del uso. Si solo es para hacer un find por una sola cosa, diccionario. Sino, depende.
#159 Imagina que es una aplicacion offline-first donde tienes que tener almacenado cierta cantidad de data, y poder modificar crear de nueva y que no se pierda en el limbo si no tienes internete
Eso requiere de guardar X cantidad de elementos de base de datos en caliente, como recorres, modificas, eliminas o a;ades elementos, o mejor dicho, que tipo de estructura usarias tu.
El objeto de objetos no me parece mal por la facilidad de hacer objetos[25].{...blablabla} mas facil que findIndex, pero claro...
#160 service workers con cache por cada llamada y almacenar el estado de la app en la cache no valdría?
Depende de como se accedan a los datos, una bd entera puedes guardarla en un diccionario por "colección", royo document db, y otro diccionario dentro por id, si solo accedes por id, y sino un btree con tus indices y un bloom filter, aunque claro... no se si te compensa complicarte tanto. Es que si me dices una bd en JavaScript, el concepto es muy amplio.
El primer nivel si te diría diccionario casi seguro, pero no lo tengo claro, depende de los datos, el tamaño y como accedas a ellos sobre todo (tus queries).
El sync por debajo lo haría en un SW que te haga de capa entre la API y la app, de forma transparente para la app.
Acabo de descubrir que los de Artsy tiene su app de iOS hecha con React Native y TypeScript, y no solo eso, resulta que es open source:
https://github.com/artsy/eigen
Esto es una puta mina de oro.
El nivel cuando entras a este tipo de ficheros:
https://github.com/artsy/eigen/blob/master/src/lib/AppRegistry.tsx
#165 dependencias no, lo siguiente. Es como hacer una aplicación abriendo un .txt en blanco. No me gusta tener que depender de mil cosas y ponerlas tú porque es una librería que viene sin nada.
Una aplicación así en flutter y seguro que en la mitad de líneas la tienes y encima nativa y con mejor rendimiento.
#166 Es el archivo madre, no es un archivo cualquiera. Es bastante normal cuando hay tanta lógica por medio y siendo una aplicación grande.
El bait es bastante claro, pero aun así te voy a dar el lujo.
Eso pasa cuando tienes segregada mucho tu lógica, no es bueno ni malo. Pasa.
Pocas aplicaciones en producción ha visto. Mis aplicaciones en mi empresa no llegan a 80 imports pero cerca estamos.
#168 ew jquery, que cancer.
#169 no controlo de este tema, pero siempre que miro cosas de React me parece un laberinto de código. No me gusta nada la verdad, y aplicaciones como esta son un ejemplo del por qué.
No pretendo crear debate, simplemente me parece picar a pedalillo innecesariamente con las tecnologías de hoy.
#171 Entonces si no sabes del tema haces un comentario pedante? SI no preguntas porque puede pasar, tu actitud no deja de ser una actitud de cuñado/ignorante que no tiene intencion de saber porque pasan estas cosas. Lo siento pero no ha sido la mejor respuesta respecto al tema.
Insisto por segunda vez, si te hubieras parado a ver que esta importando son todas las scenes de la aplicación y librerías. Esto tambien pasa en Kotlin y Java.
Esto no deja de ser una aplicación de React Native. Su manera de registrar screens a la aplicación es limpia y jodidamente escalable. A mas, que solo ensucian los imports porque están muy separados por contextos, cosa que esta genial, conjuntos de screens porque son contextos mas generales seria bastante peor ya que no sabrías porque viene de ahi. Aqui tienes un Input y un Output, sencillo. Largo? Claro, porque es una aplicación grande. Mal escrito o para que sueltes un comentario pedante? No. Sinceramente ya me gastaría ver tu código en cualquier lenguaje xd
Me recuerda a la gente que dice que la programación funcional es una mierda (o OOP)
Abro debate.
Estaríais dispuestos a pagar por un framework de React?
Los creadores de React-Router están preparando Remix, que sinceramente tiene un puto pintón. La verdad que con react-router y con reach siempre han hecho un excelente trabajo y ahora están preparando esto que sinceramente puede ser un melocotonazo.
#175 No, la gracia de las librerias que son open source. Las librerias closed source y de pago se intento hace tiempo y no funciono. Nadie los paga excepto 4 empresas y justamente cuando tienes tantísimos programadores acostumbrados a sus librerias open source.
Se van a comer una mierda y les deseo que se coman una mierda. Es un error y es volver hacia atras.
#177 Apresurado no, es pagar igualmente, verdad? Yo no he hablado de suscripion, lee bien Zoko. Cualquier libreria con paywall se merece morir, porque lo importante es la comunidad que la rodea. Si me obligas a pagar para utilizarla no me interesara y por ende no me interesara leerme ni la documentacion.
Aparte que tendras que instalarla manualmente o ellos tendrán un package custom para instalarla con npx cosa que veo cutre de la hostia.
Aparte que dicen que podemos hacer PR para arreglar bugfixes pero para que cojones el proposito de pagar si justamente no daran mejor soporte que una libreria abierta. Osea que putas mierdas se fuma esta gente? El ego bien por lo que veo.
