I see everyones using transit. Why would I use transit+json instead of regular edn?

@hkjels: It is way faster in the browser than regular edn

Ahh, ok.. I’ll leave it for now then. EDN is easier to read

It also gives you some nice extension points to add your own datatypes

It is easily changed anyway

yeah

it does seem like EDN does not approve of tempid’s

I’m not certain yet, but there’s something fishy here

Yes there is some special transit stuff to handle this

If I were you I would just switch to transit @hkjels with om.next

@hkjels: transit does have a reader to handle all of this. If you want to debug transit, just log the output of transit reader.

What are some good resources for reading about hierarchical queries in om.next? e.g. questions I have are * How do I write the parser reader that handles queries with parameters at various levels of nesting? * How do I write the parser reader such that it correctly marks arbitrarily nested queries for flattening by process-roots? I've had a great deal of headache trying to deal with parameterized queries at various levels of nesting, and the only solution I've found is to simply flatten the queries so that the top-level components manually specify all of the queries needed as a flat list (using a single set of parameters, which are used as needed in each item of the list), and sub-components only specify the shape of data they expect. This sort of seems like I'm missing one of the huge benefits of om.next and how to leverage it.

@danburton i’m trying to figure this out too at the moment, can’t find much documentation on the matter

I think something that I've been wishing for is "initialize with params". Suppose in my render function I am calling (foo-factory props). Is there any way to also initialize my foo with certain params? But then there's the issue of defining my query and correctly nesting the Foo query with the appropriate params...