Fork me on GitHub

@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?




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.

Joe R. Smith20:02:37

that’s an unfortunate restriction


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

Joe R. Smith21:02:41 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?

Joe R. Smith23:02:22

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

Joe R. Smith23:02:55

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