Fork me on GitHub
#om
<
2015-11-08
>
anmonteiro13:11:45

@jannis: suggestion: if you know the answer to those questions why not compile them into a blog post or any other write up? simple_smile

jannis13:11:34

@anmonteiro: Yep, been thinking about that. Even better to have that included in the official docs IMHO.

dnolen13:11:51

@jannis it will get documented but it’s just not priority until these problems blocking beta get sorted out

dnolen13:11:15

recursive queries & temp ident issue will probably take up the next week

jannis14:11:53

@dnolen: It wasn't meant as criticism (like "the docs are lacking this"). I'm happy to help with the documentation.

jannis14:11:46

I also think it may be a bit early to document "common mistakes" or anything like that.

dnolen14:11:02

@jannis wasn’t taking it as criticism, just explaining why it isn’t there yet simple_smile

jannis14:11:59

@dnolen: After last night's chat, I wonder if the convenience trick for transact! is perhaps the only thing that makes updates after transactions confusing. I'd be perfectly happy if we didn't do that trick at all and just forced components to be explicit about what to reread.

dnolen14:11:00

@jannis it does add some confusion, but it’s also really convenient

dnolen14:11:39

so far I prefer the convenience and would rather just document how it actually works

jannis14:11:14

Ok, no probs

jannis14:11:21

It was just a thought

dnolen14:11:37

@jannis yep I considered it but I just found myself getting annoyed when I focused on local client behavior having to specify the component itself each time

jannis14:11:02

Fair enough. With ident components being updated even with parts of the transaction being executed remotely, the number of cases where local vs remote causes different update behavior is narrowed down anyway.

dnolen14:11:27

@jannis it’s also important to consider that some people might forgo the more sophisticated remoting if for some reason they can’t provide a backend component

dnolen14:11:48

switching gears a bit - a big change to mutations

dnolen14:11:06

though it won’t break any programs since we don’t use the :value part of mutations … yet

dnolen14:11:18

the structure of :value part of mutation must now be

dnolen14:11:31

{:keys […]}

dnolen14:11:45

rather than a raw vector.

dnolen14:11:59

I’ve already updated all the docs (though feel free to fixup if you see a case I missed)

dnolen14:11:33

this is prep work for :tempids appearing in this map which will be used

dnolen14:11:00

the use case will be that you can build up complex graphs of objects client without committing

dnolen14:11:08

with temporary idents

dnolen14:11:44

then commit them - the backend can then return the real ids and Om Next will automatically migrate the temporary keys to real ones

dnolen14:11:16

this is actually huge - temporary ids + transactions are a huge problem in most client frameworks

dnolen14:11:31

this gives you a model to batch sophisticated mutations

dnolen14:11:57

you can basically transact graphs

dnolen14:11:11

and this is another feature/problem area that far as I know Relay & Falcor have no solution for

thomasdeutsch18:11:02

searching for an example with recursive reads with datascript. right now, i have a single read function that looks like this: (d/pull @state selector... ). this is fine, as long as i do not need another read function. The selector will get all the sub-queries - but i am not able to include another reader in that selector.

drcode18:11:50

@thomasdeutsch: I haven't seen an example like that- @tony.kay has examples of recursion here without datascript (https://github.com/awkay/om/wiki/Om-Next-Overview)... In the example I wrote here (https://github.com/drcode/orly/blob/master/example/src/orly_example/core.cljs) I DO use recursion and datascript, but as you suggest I also just "give up" once I pass the selector to datascript.

drcode18:11:04

@thomasdeutsch: I get the feeling though that datascript isn't going to be part of the ideal Om Next workflow- It's great that you CAN use datascript with Om Next, but I think my next app attempt will just follow the approach in dnolen's normalization tutorial, with a vanilla clojure state atom

dnolen19:11:01

@drcode: some people are actually pushing the DataScript stuff along

dnolen19:11:08

it definitely has some neat advantages

dnolen19:11:35

we’ll definitely make sure that DataScript always works well

thomasdeutsch20:11:51

just passing the selector into datascript is such a nice thing. At the moment, i am very happy with the datascript integration and as @dnolen said, it is a very natural fit. I am thinking of a possible solution for integrating other readers into the selector - but my thought experiment is out of the om scope.

thomasdeutsch20:11:11

i have this problem, because one of my sub-components needs data that is not in the selector-path - obviously.

thomasdeutsch20:11:58

allow components to have multiple queries? crazy selector fiddling thingy? ... i have no idea 😬 But i will give my feedback to a possible solution (this is all i can do for now)

jannis21:11:26

Hm. It seems that breaks normalization.

anmonteiro22:11:08

I think you have the wrong order

anmonteiro22:11:15

(query [this]
  `[({:app/people ~(om/get-query Person)}   {:foo "Bar"})])

anmonteiro22:11:19

I think this is what you wanna do

jannis22:11:19

@anmonteiro: Ah! Thanks. I didn't know that.

jannis22:11:23

Let's try that.

jannis22:11:12

@anmonteiro: You were right, thanks a lot.

anmonteiro22:11:33

You're welcome