Fork me on GitHub
#om
<
2017-03-20
>
fz00:03:32

Is there an example showing an idiomatic way to use :keys returned in the :value of a mutation function? It certainly seems useful, but I haven't found any examples of it actually being used

fz00:03:41

Related concern: it seems weird that the mutation function, which knows which keys will be stale, only returns hints, and it's up to the transact! call itself to know which keys to re-read. How should I be thinking about this?

levitanong06:03:30

It really is just a hint. It’s documentation for you and other people maintaining your code.

levitanong06:03:04

AFAIK it doesn’t do anything.

danielstockton14:03:14

(om/get-computed this) is nil and I can't work out why. Anyone have any theories?

danielstockton14:03:29

(header-factory (om/computed header {:route route
                                               :menus menus
                                               :start start
                                               :end end}))

danielstockton14:03:04

What do you do when you have a join like [{:header (om/get-query Header)}} and then header has it's own sub-components with their own sub-queries? In other words, you end up with a big nested join query where the keys have no real meaning other than to pass props down to nested components which have the 'real' query. Has anyone developed any patterns in their parser for dealing with that?

danielstockton14:03:00

Recursive parser basically.

danielstockton15:03:58

I can answer my first question, it's because props was nil.

baptiste-from-paris18:03:49

hey guys, anyone is using om-css ? I love the idea and I’d like to have feedbacks

sebn19:03:19

hello there, does anyone know of some up-to-date example of merging data saved in remote back into the om.next app state?

sebn19:03:24

I'm having a hard time figuring what I should pass to the remote callback, especially the way to replace some temporary "record" + om-generated id with its backend version

sebn19:03:56

forget about it, looks like I found my answer in om's tests

slipset20:03:21

I’ve encountered a bug in om-0.9.0 (outlined in https://github.com/slipset/troublems) which is a minimal as I can make it.

slipset20:03:04

As far as I can see, this was fixed in om-1.0.0-alpha18.

slipset20:03:56

I’ve got a workaround for it, so it’s not blocking me at the moment, but I guess it leaves two questions:

slipset20:03:18

1) how production-ready are the 1.0.0-alphas wrt classic om?

slipset20:03:37

2) any chance of having a fix backported to 0.9.0?

anmonteiro21:03:13

TL;DR: yes to 1)