This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@jannis: suggestion: if you know the answer to those questions why not compile them into a blog post or any other write up?
something like http://annapawlicka.com/common-mistakes-to-avoid-when-creating-an-om-component-part-1/ did for Om (Legacy)
@anmonteiro: Yep, been thinking about that. Even better to have that included in the official docs IMHO.
@jannis it will get documented but it’s just not priority until these problems blocking beta get sorted out
@dnolen: It wasn't meant as criticism (like "the docs are lacking this"). I'm happy to help with the documentation.
I also think it may be a bit early to document "common mistakes" or anything like that.
@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.
@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
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.
@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
though it won’t break any programs since we don’t use the
:value part of mutations … yet
I’ve already updated all the docs (though feel free to fixup if you see a case I missed)
the use case will be that you can build up complex graphs of objects client without committing
then commit them - the backend can then return the real ids and Om Next will automatically migrate the temporary keys to real ones
this is actually huge - temporary ids + transactions are a huge problem in most client frameworks
and this is another feature/problem area that far as I know Relay & Falcor have no solution for
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.
@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.
@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
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.
i have this problem, because one of my sub-components needs data that is not in the selector-path - obviously.
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)
the syntax for that is pinned to this channel (link: https://clojurians.slack.com/files/anmonteiro/F0CKAH6TS/screen_shot_2015-10-06_at_18.46.05.png )