This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-22
Channels
- # admin-announcements (4)
- # bangalore-clj (1)
- # beginners (28)
- # boot (16)
- # clara (4)
- # cljs-dev (28)
- # cljsrn (63)
- # clojure (136)
- # clojure-berlin (7)
- # clojure-gamedev (1)
- # clojure-nl (4)
- # clojure-russia (47)
- # clojure-sg (8)
- # clojure-spec (39)
- # clojure-uk (132)
- # clojurescript (66)
- # clojurex (5)
- # clojutre (2)
- # code-reviews (14)
- # core-logic (1)
- # cursive (13)
- # datavis (1)
- # datomic (35)
- # dirac (1)
- # editors (1)
- # hoplon (46)
- # jobs (1)
- # lambdaisland (5)
- # lein-figwheel (1)
- # mount (10)
- # off-topic (3)
- # om (67)
- # onyx (54)
- # planck (7)
- # proton (15)
- # protorepl (1)
- # re-frame (174)
- # ring (4)
- # ring-swagger (3)
- # specter (14)
- # untangled (15)
awesome, looks pretty straightforward. thanks @anmonteiro
is the only difference between omify!
and omify
that the first defs a new symbol while the other doesn’t?
@ethangracer: no that's not what it does
omify!
and omify
are akin to ClojureScript's specify!
and specify
, respectively
So omify!
mutates its argument, while omify
returns a copy, preserving the original JS component
You don't need to def
anything for omify!
You can (omify! js/Recharts.LineChart ...)
for example
This modifies the original component (in the library)
ah, ok got it
literally has to do with mutability
reading up on reify & specify now
There might be cases where you don't want to mutate the original object
Because some other place in your app uses it or something. That's what omify
os for
@ethangracer: also note you must use omify.core/factory
for those components
Also 1 cool thing about omify
(!) is that you can override Object
methods too :-)
interesting, i’ll have to diff the two factory methods to see the magic
and yeah I saw that! very cool
Shouldn't be the common case, but still
Did anything change in recent versions re: recursive queries? Getting a ... is not ISeqable
@denik shouldn’t have, do you have a minimal case?
actually there have been a few db->tree
fixes, there could be a regression
Happy to look at a minimal case
@anmonteiro no success reproducing yet
could it be that you were doing something that was allowed but is otherwise unsupported?
@anmonteiro not that I’m aware of
@denik: what are nested link lookups?
@anmonteiro a query like [{[:current-user '_] [{[:app-settings '_] ['*]}]}]
@denik 1) theoretically it would but there could be bugs 2) there really isn’t a recursion query there
@anmonteiro imagine recursive queries in place of [‘*]
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.
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?
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.
I'm also playing around with transaction history, but for another purpose. To get the most recent history-id: (last (.-arr (-> reconciler :config :history)))
(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))))))
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.
In other words, I'd wanted the final tx argument that om.next/transact* prints on the console
@jasonjckn not txns against the reconciler