@cjhowe We’ve built something with oracle, even. Oracle itself is a nightmare, but we’ve made it work. You can run the parser in the backend. For a great example, see here: https://github.com/anmonteiro/om-next-fullstack

@cjhowe Working on a project with mysql, no idea about datomic but compared to graphql where you write strings I really love om-next queries and full stack story. Om-next is a bit harder to grasp, but think it's really worth it in the long run (I'm going with fulcro).

ah yes, i heard about fulcro earlier! it's definitely a good project to help with grasping om-next

personally like it more. Having queries as read only from local db, seems like a nicer flow, that easier to reason about/debug. Initial state + helper functions make the developer experience a lot nicer 🙂

can do that in om-next, but then again, since I like it and it's already written, tested & extensively documented. No point in reinventing the wheel.

@cjhowe regarding you question with mysql/datomic. There is also a section in fulcro getting started with examples on how to use it with legacy 'restfull' endpoints (should apply to om-next also).

I’ve been doing a considerable amount of research over Om-next because the concepts in there are brilliant and potentially great in my line of business.

I did trip big time recently on something that didn’t seem very clear to me and my team. It seems to be some deep architectural decision that escaped me initially. It spawns out of this on the source: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1589

> “`transact!` should be called on a component that implements IQuery or has a parent that implements IQuery”

But here’s where it can get confusing. We have a parent that does implement IQuery and a few children that also implement IQuery. The parent’s query is defined combining a series of om/get-query

In that scenario, if a transact! is triggered from one of the children, the query sent to the parser will be based on the child’s query instead of the parent’s.

As a user of Om next, there are 3 alternatives to deal with it:

1. Have an intermediate component between parent and children that does not implement IQuery (it seems to be the way in most tutorials and examples)

2. Pass a reference to the parent down to the children and make sure transact! is being called on the parent instead of this

3. Use get-reconciler on the children components to get the root reconciler to pass to transact!

I’m not totally sure these options really make much sense when explaining Om next to others

Am I doing something wrong? Did I miss something here? What are your thoughts?

@luchini I usually have actions in the parent and send them to children through om/computed. So basically most of the children are dumb in regards to actions.

or if you want a refresh on a high level parent component, just add one of the keys the parent has in it's query in transact and it will get updated.

Interesting @claudiu. I was not familiar with computed. This is an interesting approach.

It does require a bit more of wiring though and reusability of the child component is now dependent on the interface provided by the parent through the computed props

I wouldn’t personally mind the mutation query leaking down to the child component because supposedly that’s the main abstraction point anyway (the same way that the IQuery of the component is an abstraction in itself)

Do you do it this way just to avoid this particular issue or do you have other uses too?

that's the way I usually do it in javascript also. Not om-next particular.

For example: listing of articles, with delete option. If I use the article component in 3 different listings, the delete functionality might be different. The listing element should not know about it's context, it just gets a onDelete.

Yes. I’ve done that in JS a lot. I was hoping om-next would remove the need for that abstraction (by having its own separate abstraction system) 😄

😄

@luchini This might be a bad idea, but you could pass a partially applied transact to the child component

partially applied to the parent component (partial om/transact! parent-this)

True… 🙂 It’s like option 2 above… but fancier 😄