Fork me on GitHub

When writing a server for Om Next, should queries use GET and mutations use POST? Is there a non-trivial server example? Is the om-next-demo a good example to use?


App state lives in a single atom as a map of key value pairs?


Did I get all or part of that right?

Oliver George01:02:47

Quick shout out to @jannis who is posting some beautiful code on github using

Oliver George01:02:23

After looking at the kanban demo I was tempted to poked around his other repos.


@olivergeorge: Thanks for the praise simple_smile I'd like to point out that most of the other repos are experimental at this point. Props to everyone who finds the time to actually finish stuff! 😉


anyone know why I’d get “No queries exist for component…” :


the meta path and query are correct for the child


if I make up a keyword instead of ident it doesn’t complain 😕


but I mean … I should be able to use idents in a root query no?


@hueyp: I don't think they are supposed to work


Your queries must match the shape of your state


Hi, I'm a little confused on how to use normalized state with figwheel reloading... so I have (defonce app-state (atom ...)) to make figwheel retain state on reloading and :normalize true on my reconciler, so everything works great when I reload my page. But the problem is if I update a source file, figwheel tries to re-normalize my already-normalized state, and bad things happen. Questions: Is normalization meant to be idempotent? (i.e. you can normalize already-normalized state without errorrs... I suspect the answer is "no, you should only normalize things once.") If not, is the correct solution to this problem to do (defonce reconciler ...) as well? Thanks!


@drcode: in short, you should also defonce the reconciler


I've written about reloadable code & Om Next. Here's the link, if you're interested:


Thanks @anmonteiro very helpful, that post is exactly what I needed!


@anmonteiro: the parser / data works fine … the app-state is : {:person/by-id {2 {:id 2, :name Erik}}, #{}}


and it renders the data, the path-meta is set, etc


I’m thinking of the use case of a route like /user/{id} … not sure how else to handle that then querying directly by ident


anyone have examples of routing using set-query?


I’m thinking of a route like /user/friends/{friend-id} … I’m not sure how I can call set-query on the root, but kind of cascade route params from top to bottom


like if your component path is ’(Root Friends Friend), each of their queries depends on the route, but you wouldn’t want to call set-query on each of them


in my mind you could pass down context from the root … like (om/get-query Friends {heres-some-route-infos})


@hueyp: You can, sort of. ({:friends (om/get-query Friends)} {:param1 val1 :param2 val2...})


I was wondering if this had any use in (query …)


oh nvm I misread


so now the parser is doing the routing?


In that example bidi's router translates URLs to an app state / set-query calls. And it also supports translating app state back to a URL that is then set in the browser (via activate-route!). It's not ideal because in my solution, all app data is queried regardless of which route is active. But that could be changed by changing more than the query params in navigate-to.


thanks, I’ll take a look simple_smile yah, I was kind of thinking the query function could be dependent on state and only return the active query … but you can’t really accomplish that, right? like that logic of route->query needs to live outside the component?


I should read your example before asking questions 😜


regarding my “No queries exist for component path…” … it appears when you focus a query along a path with an ident, it works fine, but when you ask for the focus path, it returns something else


e.g. I focus it along the path [[:person/by-id 2]], but focus->path gives back [:person/by-id] as the focused path


which then om full-query gives an exception


focus->path just drops the second part of the pair


so this works fine for stuff like [:current-user _], but not so much [:user/by-id 1] 😜


[:current-user _] is not a regular ident.


It's special-cased in the parser as being a read at the root level of the query (IIRC)


my understanding of the documentation is that if any ident is encountered in a query, its parsed from the root


I have zero idea if that is a bug or not


I have no idea either. However, the first lines you pointed at do special-case [:foo _] and that means different behavior.


yah, I’m wondering if that same check on _ is required in focus->path … made an issue : … might just be “don’t do this” 😛


I feel like idents are my main struggling point … they seem like the main concept for keeping things consistent, but I keep hitting issues thats stopping me from really understanding


Is it Idents or fact that you are changing the queries (so it is not a static setup), or a combination of these two?


naw, two separate things … I’m way more interested in idents and how they work … the dynamic query stuff is a curiosity of how I’d do routing in


I’m coming from relay / graphql … so I have baggage of wanting to query by ident … e.g. query { node(id: 2) { id name } } => [{[:node/by-id 2] [:id :name]}]

currentoor23:02:18 Has anyone recently gone through the remote sync tutorial? I copied and pasted the examples directly into my file and still can’t it to work.


Is there an example of the complete source for this tutorial?