This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-03
Channels
- # adventofcode (1)
- # beginners (76)
- # boot (88)
- # cider (63)
- # clojure (357)
- # clojure-austin (2)
- # clojure-berlin (8)
- # clojure-brasil (8)
- # clojure-nl (1)
- # clojure-russia (22)
- # clojure-spec (17)
- # clojure-uk (47)
- # clojurescript (67)
- # cursive (45)
- # datascript (3)
- # datomic (45)
- # dirac (7)
- # emacs (3)
- # funcool (2)
- # hoplon (26)
- # jobs (2)
- # jobs-discuss (11)
- # luminus (6)
- # off-topic (243)
- # om (40)
- # om-next (7)
- # onyx (23)
- # overtone (1)
- # portland-or (2)
- # protorepl (11)
- # re-frame (55)
- # reagent (58)
- # rum (12)
- # sql (4)
- # test-check (12)
- # untangled (25)
@alex-glv I believe reads should be non normalized. db->tree is called in reads and this function denormalizes.
A question on Compassus, why isn't the parser getting invoked?
(defmulti read om/dispatch)
(defmethod read :index
[env k params]
(js/console.debug "Read called")
{:value "Hello"})
(defui Home
Object
(render [this]
(let [text (om/props this)]
(html [:div text]))))
(def app
(c/application {:routes {:index Home}
:index-route :index
:reconciler (om/reconciler
{:state {}
:parser (c/parser {:read read})})}))
(c/mount! app (js/document.getElementById "app"))
@fenton so I shouldn’t do anything explicitly to normalise data to be able to use refs and idents? My problem is data gets merged into the state but it doesn’t get normalised. I am left with the actual results from the database (datomic), so I am trying to figure out if I need to do anything extra in reading, or something wrong with the query / components.
@fenton Also, I noticed that if I don’t specify my custom merge function to reconciler, I get extra key in my result map
:om.next/tables #{}
does it mean om failed to find relevant idents and normalize?@asultanpur: because your Home
component doesn't have a query
Do I need to have a query even when I’m dispatching based on current route, by letting :route-dispatch
remain as true
?
Your parser handler for any given route refers to the data that the component for that route needs
i have a Compassus app which has its initial state correctly normalized by the app, but when a remote is called the ui is rendered as expected but the new data is not normalized and merged back into the app state. Is this the expected behaviour?
@tmulvaney: that's not enough information
Are you calling the send callback with the appropriate query to normalize the novelty against?
@anmonteiro I'll get back to you. You may have nudged me in the right direction 😉
yep passing the novelty and the query did the job! Thanks @anmonteiro
I didn't realize the callback took query as an argument as well. The example at https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial seems to only involve passing the novelty.
@tmulvaney it's buried in here https://github.com/omcljs/om/wiki/Documentation-(om.next)#reconciler-1
This callback is multi-arity. With one argument, pass the novelty. With two arguments, pass the novelty as the first argument, and then pass a query as the second argument.
OK. So the fourth arg to merge (query) is passed in via the cb. I was wondering why it was nil whilst trying to solve my original problem. Things are making more sense 🙂
what are the pros and cons when using IAtom as :state in om.next/reconciler compared to just plain map?
i'm exploring the example in om.next's Thinking With Links and the state is not normalized when i change init-data
to IAtom
i tried to setting :normalize true
in om.next/reconciler option but the state is not normalized
(def my-reconciler (om/reconciler {:state init-data ;; atom :parser (om/parser {:read read}) :normalize true }))
@mavbozo :normalize true
in the reconciler instructs Om Next to normalize remote responses, not the initial state
if you want to pass an atom to the app state, you need to pre-normalize it yourself
using om.next/tree->db
for example
Getting Uncaught ReferenceError: React is not defined
after defining some queries in ident+query only components, found this issue but could not resolve by adding om.dom https://github.com/omcljs/om/issues/475
@anmonteiro cool, (om/tree->db SomeList init-data true)
returns
{:current-user {:email ""},
:items [[:item/by-id 0] [:item/by-id 1] [:item/by-id 2]],
:item/by-id
{0 {:id 0, :title "Foo"}, 1 {:id 1, :title "Bar"}, 2 {:id 2, :title "Baz"}},
:om.next/tables #{:item/by-id}}
hello guys, little typo in the doc of om-next
here => we can easily we
https://github.com/omcljs/om/wiki/Queries-With-Unions
Finally notice that because queries are just regular ClojureScript data we can easily we get some extra bit of information. We tack on :favorites to each subquery. We will be writing shared favoriting logic shortly.
@baptiste-from-paris feel free to edit
ok, it was written ‘DO NOT EDIT’ but ok
the DO NOT EDIT
part refers to content, not typos
to prevent people with insufficient understanding of Om Next to introduce mistakes in the tutorials
I just noticed that this code ex from the doc bugs (if someone can confirm)
(defmethod read :dashboard/items
[{:keys [state]} k _]
(let [st @state]
{:value (into [] (map #(get-in st %)) (get st k))}))
error =>
:dashboard/items is not ISeqable
to make it work =>
(defmethod read :dashboard/items
[{:keys [state]} k _]
(let [st @state]
{:value (into [] (map #(get-in st %) (get-in st [k])))}))
@anmonteiro Your advice to use browserify to exclude react was spot on- It solved my problem (with a couple of extra tricks to tweak the output of browserify) thank you so much!
@baptiste-from-paris Hmm.. in the tutorial it mentions "Of these the only one that should be at all surprising is DashboardItem. Instead of returning a vector it returns a map." .. but I'm gonna do some investigating and see