Fork me on GitHub

@vinnyataide Hi, I'm having some difficulty understanding your question. First of all, are you using Om or OmNext? Most people on this forum have been using OmNext recently, if it's an Om question I'm afraid many of us are probably a bit hazy about how things worked in "the old days" 🙂 but we'll try to help if we can.


and thanks for trying to understand, it is about how relay handles colocation


you put your queries besides your components


in the same file


and mutations in a separate folder


my question is there a way for such or like such thing in om next?


@vinnyataide :thumbsup: So the typical answer to maybe 70% of OmNext questions ends up being "put the logic in your parsers"- So in your case I would recommend thinking of OmNext component queries as being very "dumb" and not true queries- They are more of a "list of stuff", mostly open for interpretation by the query semantics, which the programmer is mostly in control of. The real brains for non mutating queries are in the read parser functions, and the brains for mutating queries are in the mutate parser functions. Those, you can co-locate in the same file, separately from the components.


Don't think that in OmNext "queries and components are colocated" even though that's technically true. The queries in components are really just a way for components to say "Hey parser functions, here's the shape my data needs to be in for me to do my job"


@vinnyataide hopefully I didn't just go off on a rant that has no bearing on your actual problem 🙂


@vinnyataide components in OmNext are not truly "data aware" in the same way as in some other frameworks, by design. The only "data awareness" they have is (1) they can publish a "list of stuff" they need in the IQuery declaration (2) they can fire off transactions, which just send "plain old data" to a magical outside location.


@drcode that seems really well put, not a rant at all, it's just that I know how to build om next apps, I just don't know the best practices because I never went big, thanks for a good answer


@vinnyataide Personally, my preferences in large projects is to put related parser read and mutate functions together, but keep them far away from the components... not sure if everyone here does it that way.


@drcode yeah, I tend to think the IQuery as the read function, because it's that how relay works


and I think om next handles decoupling better


@vinnyataide Yeah the problem is that in my view "Graph Queries" are not really "Queries" in the old fashion sense, because good ol' SQL was all about data transformations, whereas the benefit of "Graph Queries" (such as in the iQuery declaration) is precisely that they free your components from having to do data transformations, which are brittle, because they introduce dependencies on the structure of the data source- All the data transformations are relegated to the parser functions


@drcode I think relay is this way as well, it's just different that it couples the IQuery part with the read function


:thumbsup: Studying relay is on my todo list


since om-next was inspired in relay I think it went further with decoupling


if you know graphql its gonna be a breeze


Hi OmNext community: I've put up 2 polls on Twitter that I'd love your feedback on: I am a huge fan and user of OmNext since the very beginning, but there are two (relatively minor) pain points that bite me again and again with OmNext- I'm just curious if I'm an outlier with these issues (maybe they're actually simple matters for other users) or whether it makes sense for me to brainstorm some alternative approaches for these two small pieces of an otherwise fantastic system. Thanks for your input!


@drcode how do you feel about untangled ?


Do most people just selectively show and hide elements based on "navigation"?