hello everyone

I’m struggling with the om.next parser implementation

i have implemented the “read” method as a multimethod as shown in various tutorials

and when it comes to read queries with joins

I call the parser recursively

the problem is: how I can recover the possibility to ask for remote call when I use the parser recursively?

parser only return a value

and I need the :remote key from my read methods

I can make an example if someone would like to help me

@rastandy are you using om/db->tree?

@wilkerlucio no, I have a custom database format

the problem for me is that if I call the parser recursively from “read”, I lose the possiblity to ask for remote call from my read methods

umhum, I see the issue, I don't know how to solve that using a recursive parser

are you doing it for the sake of learning or just trying to get something working?

trying to get something working

and learning

😉

🙂

had you tried the Untangled framework?

I’m trying to convince my colleagues to go for om.next in our projects

@wikkerlucio No, I can’t chose the backend

only frontend

and interface with a rest api

you don't have to choose the backend

I for example only use the untangled-client

ah

interesting

because it saves me all this work on the parser

at least on the client-side, on the server-side I'm using cljs + node

I don’t know if I’ll have time to change the app

but it’s a good suggestion for the next app

thank you

no worries, if you have some time take a read on their docs: http://untangled-web.github.io/untangled/reference/reference.html

@rastandy: here's an example of solving the problem you're having: https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs#L191

@anmonteiro thank you, will take a look at that

btw, @anmonteiro thank you for your great talk “Clients in control”, I really enjoyed that, and also I started reading your blog

Thanks, always glad to be of help

🙂

Here's how I've been doing it @rastandy. https://gist.github.com/petterik/abfae9d8383138b2daa83588e4c7a9fb

It's a bit hacky and I should probably look at the om-tutorial version. Just thought I'd provide another example

@petterik wow thank you very much, I’ll try to understand all this suggestion

@petterik I’m not able to understand your solution, maybe when I’ll go deeper in this problem

@rastandy I didn't understand it either. Was a long time since I hacked it together. So I made it better: https://gist.github.com/petterik/abfae9d8383138b2daa83588e4c7a9fb

which is now pretty much an inline version of the om-tutorial version, without the (decend ) code

@petterik thank you 🙂

Thanks for letting people know that Untangled doesn't force you into a back-end @wilkerlucio. That seems to be a common misconception. It is really just a collection of libraries that, taken together, provide a full-stack solution. But just in case others are wondering: The client and server libraries don't have any opinion on back-end database. There is a Datomic integration library that adds some helpers for that, but you could easily use PostgreSQL, MySQL, etc etc etc. Even the testing library (untangled-spec) is a stand-alone library that you can use stand-alone. Basically, Untangled makes it easy to get going on an Om Next app (you don't have to write a parser, network plumbing, etc.). You do have to tolerate a few decisions (e.g. we pick the "default" database format, and provide more complete merge/migration implementations), but we've not had a single complaint about that. We also give a server interaction story that is pre-constructed, but it uses stock Om-Next primitives...it just does a lot of the work you'd have to do anyway. We're in the process of updating the docs (the tutorial is becoming a dev guide...feel free to check out the progress on the develop branch of https://github.com/untangled-web/untangled-tutorial/tree/develop

thanks @tony.kay for the explanation

@rastandy Did you ever find an answer about calling the parser recursively?

Oh, my Slack's scrolling poorly 😛

@tony.kay your tutorials are awesome and Untangled looks very cool!

@rastandy This is where you're mistaken, but it's an easy mistake to make.

@peeja I’m still in the process of learning from @tony.kay’s om-tutorial

The parser is actually called twice: once with target set to nil, and once with it set to your remote name (and then again for each additional remote you have)

When target is nil, it'll return the value of the :value key. When target is a remote name, it'll return the query you return for that remote.

so you actually do get the remote query when you're parsing recursively, you just have to make sure to call the parser with the target

@peeja interesting, are there some example of this? I’m not sure I understand the call graph 😞

Also, the :remote key in the map you return from your read expects an AST (or true, to include everything), but the parser returns a query. You'll need to covert that query back to an AST to include it recursively in another read invocation.

I don't have an example to point to, but you can see it happening here: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1267-L1273

gather-sends calls the parser once for each remote

And here (if I'm reading right) is where it calls it without a target: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L2560

uhm thank you @peeja, looks like I have a lot to understand for this weekend

The weird thing is that your read generally returns a map, but the parser is only ever paying attention to one of the keys in that map. Which key it cares about depends on whether it was invoked with a target (and if so, which one).

You can also check the value of target in the env from your read and only calculate the :value or the :remote as appropriate, if you'd like.

For instance, we're doing this:

(defn read [{:keys [target] :as env} key params]
  ;; Dispatch to either read-local or read-remote. Remember that, despite the
  ;; fact that a read function can return both a :value and a :remote entry in a
  ;; single map, the parser is actually only looking for one or the other during
  ;; a given call, and the presence or absence of target tells you which it is.
  (case target
    nil {:value (read-local env key params)}
    :remote {:remote (read-remote env key params)}))

We found it wasn't useful to make read the multimethod; instead we've got a read-local multimethod and a read-remote one.

Almost every key uses the default read-local, which is just db->tree

but lots of keys have special implementations for read-remote

I’m trying to understand your suggestions, but I think I need to study the source first, because the process is still obscure to me

Yeah, it's one of those things 🙂

Keep slamming your head against the things that don't make sense until it all clicks. That's how I did it. 😛

@peeja hehe, it’s how I’m doing right now, but my problem is time

I need to make a working demo very fast or else people will think this is a too complex solution to use

but I will try hard, I feel like there is nice panorama after the tip of the mountain 😉

If you can get away without calling the parser recursively, it'll probably help. It takes a bit of massaging to do it right. Even if that's ultimately the right thing for your app, it may not be worth the time for a prototype

@rastandy Thanks. One of the main reasons we built and open-source it is I realized a number of things were a bit hard to reason about (like the stuff you're discussing right now with remotes). I saw a number of generalizations (e.g. when you want to remote: you end up marking things in state, running a parser to figure out how to do things...which just looks at something you invented in state, and then return the whole remote true/ast. I realized that you could build all of that in, so you didn't have to write all of that. The load story becomes explicit calls instead of these convoluted constructions of parser/state)

and you get things like "loading markers", no need for process-roots, etc. The main trade-off is that you move away from a parser and towards explicit post-read data transforms.

but I personally understand transforms more easily than parser logic

The overall model is mostly preserved (which is awesome, because David designed something really cool here), but most of the pain evaporates.

I’m starting to convince myself that trying to use Untangled could save me time

@tony.kay If I can query a REST api without writing any server code, I think I can give it a try

@rastandy The whole Om Next model is to avoid REST...can't help you there

We wrap an external REST api with our Untangled server, if that helps, it's a bit of indirection, but lets us be more flexible.

well, actually, you could replace the networking component on client. That is supported

Then you could do the transform to/from REST in the client

now that I think about it. You lose a lot of cool things, but you could do it

That's actually an interesting use-case for a plugin 🙂

hehe that would be nice .D

😄

just implement untangled.client.impl.network/UntangledNetwork (two functions, only one of consequence).

then pass it as :networking when you make an untangled client

you get the EDN, and would transform it to REST, then call the provided ok with a proper Om Next response transformed from the REST response

Taking @therabidbanana 's approach is better, because then you get all the coolness of other bits as you add new functionality.

saving your messages for when they’ll make sense, after reading the Untangled tutorial

@tony.kay I think that having a good story for REST api’s is nice because it’s easier to convince people writing the frontend that om.next and clojurescript are awesome

than trying to convince to rewrite big REST services all at same time

@rastandy If that's what you're doing, though, you're losing some of the best parts of the Om Next story.

@tony.kay I know, but I’m trying to find a breach for om.next in my corporation

If I win with the frontend guys, things will be easier on the backend

I see

@rastandy I hope you convince them! You and your corporation are very welcome to this community

having a responsive and helpful community like this is a very good start 🙂

@rastandy If you'd like some tips on the transforms, I'd be glad to help

@petterik I hope it too! Frontend development is awesome with clojurescript and om.next!

@tony.kay thank you very much!

I'm sorry if it's already covered somewhere, but I suddenly realized that I don't understand why :foo/by-id is a common idiom in Om land. Why :foo is a namespace here? As far as I understand, we don't usually have :foo/by-id, :foo/by-bar, etc. Why not :by-id/foo?

does anyone here knows if there is a way to access React private API's from the compiled version? I want to use the ReactMultiChild mixin (used by people on react-canvas), but I can't figure how to access it

@si14: also curious about the origins of :stuff/more-stuff when they're not strictly namespaces. My bet it's coming from Datomic