clojure-argentina

2017-07-20T18:25:25.678126Z

che @nberger cuando tengas un min me tirás un par de líneas sobre por qué preferís reagent/re-frame por sobre om/om.next

2017-07-20T18:25:37.684990Z

(es por el proyecto que te contó @unbalancedparentheses)

2017-07-20T18:27:48.758506Z

(y obvio que si alguien más del channel tuvo experiencia con alguno el input es bienvenido 🙂 )

nberger 2017-07-20T22:51:19.940587Z

@facundo en realidad creo que es más bien que estoy acostumbrado a re-frame y me parece más fácil para arrancar. Pero re-frame tiene un gran problema que es la DB global y única. Y creo que om.next tiene grandes ideas y en una app grande pinta que está piola usar el ¿parser? para resolver partes de los queries a servers diferentes, o si tenés datomic detrás entiendo que podés usar datalog tanto en el cliente y el servidor y lograr algo tipo graphql bastante fácil... Los dos son opciones válidas creo, si después podés compartir tu experiencia sería genial :)

2017-07-20T23:03:26.143465Z

por lo que vi om.next también tiene el átomo global o no?

2017-07-20T23:03:52.150795Z

a primera vista re-frame me parece más idiomático

2017-07-20T23:04:10.155195Z

om y om.next usa mucho protocolo, reify

2017-07-20T23:04:20.158065Z

usa funciones para el dom en vez de estructuras tipo hiccup

2017-07-20T23:04:27.159937Z

asi que a nivel sintaxis me gusta más reagent/reframe

2017-07-20T23:05:04.169799Z

por lo que estuve leyendo om garpa más para proyectos complejos

2017-07-20T23:05:11.171677Z

no es nuestro caso, esto es bien sencillo

2017-07-20T23:05:18.173505Z

asi que en principio vamos con reframe

2017-07-20T23:05:21.174254Z

I have my concerns about om-next, but overall since I’m writing a complex side-project, it’s worth it. If I had to ship something tomorrow, I’d go with reagent still, but for longer projects where you can spend more time and get over some learning curve and alpha/beta type bugs, om-next is a good fit for large projects. I found reframe to be generally the best way of working with reagent, but not as good when I had lots of chained events and complex queries. I spent a lot of time optimizing around some ways that reagent/reframe does things where as in om-next, I could tweak things more to my needs. Om-next also offers some additional features many people don’t need, but fit my use-cases well (ex: server-story, pulling only what you need, normalizing client app db data).

To summarize, reframe is a nice framework and really great for small projects or projects that need to ship today. It works and is the best approach I’ve seen on top of reagent (and react). Om-next is good for people that can afford to take some risks and have complex requirements but still want a proper framework on top of react. Om-next will make you do a lot more work up-front and has a lot more ceremony, but there is a reason it exists. Generally, I have found om-next powerful once you are able to grasp the way it wants you to do things. For people who want something like reframe like om-next, there is the “untangled” framework. Anyway, I wouldn’t recommend om-next or reframe/reagent over the other, rather I’d suggest either and match your requirements accordingly.