Fork me on GitHub
#clojure-argentina
<
2017-07-20
>
facundo18:07:25

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

facundo18:07:37

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

facundo18:07:48

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

nberger22:07:19

@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 :)

facundo23:07:26

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

facundo23:07:52

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

facundo23:07:10

om y om.next usa mucho protocolo, reify

facundo23:07:20

usa funciones para el dom en vez de estructuras tipo hiccup

facundo23:07:27

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

facundo23:07:04

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

facundo23:07:11

no es nuestro caso, esto es bien sencillo

facundo23:07:18

asi que en principio vamos con reframe

facundo23:07:21

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.