Fork me on GitHub
#om
<
2016-08-22
>
ethangracer00:08:29

awesome, looks pretty straightforward. thanks @anmonteiro

ethangracer00:08:57

is the only difference between omify! and omify that the first defs a new symbol while the other doesn’t?

anmonteiro00:08:26

@ethangracer: no that's not what it does

anmonteiro00:08:08

omify! and omify are akin to ClojureScript's specify! and specify, respectively

anmonteiro00:08:58

So omify! mutates its argument, while omify returns a copy, preserving the original JS component

anmonteiro00:08:33

You don't need to def anything for omify!

anmonteiro00:08:11

You can (omify! js/Recharts.LineChart ...) for example

anmonteiro00:08:38

This modifies the original component (in the library)

ethangracer00:08:53

ah, ok got it

ethangracer00:08:03

literally has to do with mutability

ethangracer00:08:15

reading up on reify & specify now

anmonteiro00:08:44

There might be cases where you don't want to mutate the original object

anmonteiro00:08:25

Because some other place in your app uses it or something. That's what omify os for

anmonteiro00:08:39

@ethangracer: also note you must use omify.core/factory for those components

anmonteiro00:08:40

Also 1 cool thing about omify(!) is that you can override Object methods too :-)

ethangracer00:08:01

interesting, i’ll have to diff the two factory methods to see the magic

ethangracer00:08:10

and yeah I saw that! very cool

anmonteiro00:08:18

Shouldn't be the common case, but still

denik14:08:33

Did anything change in recent versions re: recursive queries? Getting a ... is not ISeqable

denik14:08:16

between alpha40 and alpha41

anmonteiro14:08:31

@denik shouldn’t have, do you have a minimal case?

anmonteiro14:08:18

actually there have been a few db->tree fixes, there could be a regression

anmonteiro14:08:42

Happy to look at a minimal case

denik16:08:10

@anmonteiro no success reproducing yet

denik16:08:28

prev version was actually alpha34

anmonteiro16:08:11

could it be that you were doing something that was allowed but is otherwise unsupported?

denik16:08:30

@anmonteiro not that I’m aware of

denik16:08:01

could it have to do with nested link lookups?

anmonteiro16:08:00

@denik: what are nested link lookups?

denik16:08:14

@anmonteiro a query like [{[:current-user '_] [{[:app-settings '_] ['*]}]}]

anmonteiro16:08:42

@denik 1) theoretically it would but there could be bugs 2) there really isn’t a recursion query there

denik16:08:24

@anmonteiro imagine recursive queries in place of [‘*]

denik16:08:34

ok, will dig deeper

alpheus19:08:35

It looks like there's no access to Om's transaction history (except by looking up a transaction by the uuids logged to the the js console). I saw ITxIntercept but not sure how that would be used.

alpheus19:08:31

I had thought of logging the last transaction, and a diff of app-state before and after for debugging purposes. Is that a bad idea?

alpheus19:08:05

The goal is to write clojure.spec for app-state, add a watch to the app-state atom and validate as it changes. Logging why it changed seemed helpful.

petterik19:08:48

I'm also playing around with transaction history, but for another purpose. To get the most recent history-id: (last (.-arr (-> reconciler :config :history)))

alpheus19:08:20

That is all I needed. Didn't know about -arr

jasonjckn20:08:25

@alpheus i do DIFF on app state, it's a wonderful debugging tool

jasonjckn20:08:53

@alpheus TX history isn't the only way to DIFF app state, here's what I do

jasonjckn20:08:32

@alpheus

(defonce install-app-state-diff-once
  (add-watch app-state :app-state-diff
             (fn [_ _ old new]
               (let [d (diff new old)
                     d (filter-keys #(not (#{"untangled" "om.next"} (namespace (first %)))) d)]

                 (if-not (empty? d)
                   (js/console.log "APP-STATE DIFF: " d))))))

jasonjckn20:08:38

in other words, I use a watch

alpheus20:08:19

we're doing almost exactly the same thing

jasonjckn20:08:51

what did you use for your diff function?

jasonjckn20:08:53

just curious

alpheus20:08:58

clojure.data/diff

alpheus20:08:02

I misunderstood what the reconciler history was for -- I'd hoped to get the transaction, not the state. With a watch, I've already got the state.

alpheus20:08:47

In other words, I'd wanted the final tx argument that om.next/transact* prints on the console

jasonjckn20:08:05

i think you need to wrap transact in your own function for that

alpheus20:08:00

Coming full-circle, implementing ITxIntercept gives you the tx after all.

jasonjckn20:08:38

does ITxIntercept let you intercept all transactions?

jasonjckn20:08:28

what if you transact on the reconciler

anmonteiro20:08:37

@jasonjckn not txns against the reconciler

jasonjckn20:08:53

would be nice to support a way to intercept all transactions I think that would be useful

jasonjckn20:08:00

although I don't have a specific use case in mind atm

alpheus20:08:02

what should tx-intercept return?

jasonjckn20:08:08

the transactions

jasonjckn20:08:24

[(...) (...)]

alpheus20:08:39

but in the loop, the return value of tx-intercept is assigned to parent

alpheus20:08:08

(the loop inside om.next/transact!)

alpheus20:08:50

uh, maybe I'm mis-reading that

alpheus20:08:46

oh, ignore me