@drcode Any luck getting blueprint working with new module support? Be interested in seeing the config/usage.

@anmonteiro That would be one way, although you'd lose the advantages that come from a single state container (easy to debug and to implement time travel). Are there any other advantages that could come from a single state store (thinking of datomic where schema = data)? For example, if the indexer was also in app-state? You could have components which can directly query the indexer, might be useful for implementing fancy debuggers or something? I don't have a use case in mind, just a random thought.

Is there a reason vectors are used over sets to store children nodes in the query AST? Is the order of things important? Asking because i'm trying to write some code to diff/merge queries and converting to AST form first makes sense.

@tmulvaney Queries are also vectors. Perhaps order is important, because it allows query->ast and ast->query to work consistently and determinably?

Yeah although you could argue [:person/name :person/age] and [:person/age :person/name] produce the same thing {:person/name ... :person/age ...} an associative and orderless collection and are thus equivalent queries.

I'll just walk the ast and tack on a set version of children to make my life easier.

@tony.kay haven't yet, waiting for an official version of Om with react module refactor- Though anmonteiro's repo may already be a good starting point...

@tmulvaney I always figured the reason vectors were used was mainly easy readability and easy differentiation from maps, but I don't know that for a fact.

@drcode it was more the use of the vectors to represent children in the AST as per query->ast as i wanted to write some functions for manipulating queries and doing so on the AST made more sense as its easier to manipulate. I certainly agree that for queries, vectors are more readable.

@tmulvaney oh yeah, good point

@drcode: FWIW you shouldn't expect Om to consume React from node modules anytime soon

My branch was just an experiment, node module consumption is meant to be for applications not libraries

@anmonteiro thanks good to know- It take it that means if another npm module has react as a dependency, extra steps will remain necessary to prevent double-loading of react?

Most likely

:thumbsup:

Has anyone been working on Om Next / GraphQL interop yet? I'm thinking through the possibilities for translating Om Next EDN to GraphQL, and I notice that / isn't allowed in a GraphQL name, which kind of puts a damper on it.

that’s an unfortunate restriction

What is the clojure equivalent for GraphQL anyway? The datomic pull API?

Om.next has a query language (I guess it’s the Om Query Language). It’s similar to the Datomic Pull syntax

Yeah, but how does that translate to remote queries?

The queries for each component in the component tree are composed together and, optionally, sent to your remote

e.g., if my read parser returns a map {:remote true}, the query will be sent as is to my remote named :remote. Optionally, you can manipulate the AST before sending it off