This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-08
Channels
- # admin-announcements (3)
- # alda (2)
- # beginners (66)
- # boot (54)
- # cider (21)
- # clara (1)
- # cljsfiddle (32)
- # cljsrn (9)
- # clojars (4)
- # clojure (164)
- # clojure-dusseldorf (4)
- # clojure-japan (2)
- # clojure-norway (1)
- # clojure-russia (76)
- # clojure-sg (8)
- # clojurescript (19)
- # core-async (1)
- # core-typed (1)
- # cursive (6)
- # datomic (1)
- # editors (48)
- # hoplon (20)
- # immutant (2)
- # jobs-discuss (6)
- # ldnclj (1)
- # om (82)
- # onyx (6)
- # parinfer (11)
- # proton (2)
- # re-frame (113)
- # reagent (17)
- # testing (11)
- # untangled (11)
- # vim (4)
- # yada (38)
I see a few discussions related to datascript and om.next. There are a couple of demo applications but all of them client only apps with no server side integration. Are there any issues I should be aware of before I go down this route ?
im trying to make sense of the om next todomvc example. currently i've set up everything so that I can send a query to the server and get the correct response back in the callback I gave to send. I verified that I can translate it from transit to json. I now expect this data to be properly represented in my app-state, but its not. I'm looking at the state key in the env argument that the root read function receives and it is malformed. I'm not sure what to do at this point, any ideas?
#object [cljs.core.Atom {:val {:todos/list [[:todos/by-id nil] [:todos/by-id nil]], :todos/by-id {nil {:db/id 17592186045419, :todo/completed false, :todo/title Walk dog}}, :om.next/tables #{:todos/by-id}}}]
@matthavener: What is dc
?
well, you were right on the money. I was using (let [{:keys [id] ..}]
when it should have been db/id
tawus: do you know of any other resources for learning besides the github docs and awkay's tutorials?
There are a few articles here http://anmonteiro.com/
@seanirby: By the way there's a pretty simple library that picks up those kind of mistakes for you: https://github.com/chrismurrph/default-db-format. I wrote it because I make them quite often.
With it you don't have to think "oh maybe I should look at @reconciler" - it will tell you when the problem first happens, and pinpoint where it is.
@cjmurphy: It gives me Not normalized in tables problems:
for code/name which is a string.
Hi @tawus. The rules for what is acceptable include a String (nil? number? string? boolean? ident? vec-of-idents? etc all acceptable as table data values). That sounds like a bad error message thou. You can exclude top level entries that are not supposed to be inspected. Also there is also an 'escape hatch' function you can supply for saying what is acceptable - but that is only intended for complex objects. Would you be able to submit an issue with the result of @reconciler
? Components and initial data would be good too but I can hopefully work them out if its not too huge.
I can create an issue, if it is really a bug. May be my state is an issue which it is correctly depicting.
@tawus: It was a bug. My list of things that are real data didn't include keyword?
. I'll release a new SNAPSHOT in a moment but for now you can just put :acceptable-table-value-fn? (fn [v] (= keyword? v))
into the input hashmap, which I'm guessing you've already used for excluding :app/route
and :om.next/tables
. Will private msg you...
strange. i have this om-0.8.8 project, works nicely, haven't touched it for three months and now advanced compilation dies with stack overflow error
cjmurphy: devcards.. I can add a full ns form of youd like to try it 😄
tawus: yeah, it just ignores the params
right? params have no effect on tree building, they’re just for changing the effects of read/mutate functions
So how do you handle such a situation ? Say When you are trying to filter a list by some parameter and the whole list is on the client side
you want to filter a list but using a short reader that just does get-in with db->tree ?
you could always recurse into the parser to handle that read with your params to filter there
i’m pretty new to om.next though so take any of my advice with a large grain of salt 😛
@tawus Keep the full list in one key in the state and have a reader handle a filter key that takes params and does db->tree on the full list key, filters the result and returns the denormalized filtered data. The reconciler will denormalize it and cache the filtered list in the state under the filtered key.
When you change the params, the reader should get called again to update the filtered list
@matthavener: yes I was thinking of using just db->tree.
@cmcfarlen: that is what I am currently doing! But I think it should be supported out of the box by db->tree
hi all, why is he using postwalk here? won't you end up recursing through the entire :db-before and :db-after values? https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/clj/todomvc/server.clj#L42
@seanirby: no, they're just references
@anmonteiro: thats what I originally thought, but i dropped in a println in that fn and thats what it seems to be doing.
@tony.kay thanks, i ended up using your approach and it most definitely works with c3 as well thanks for the input
why does a parent rerender when it passes a computed callback to the child, but not if the child invokes the same function directly (without it being passed in)? the function changes some child data, but in the value map I instruct for a read of the parent data to happen. is it not possible without passing in a callback?
for ref here are my mutate fn and simple state
(defonce select-test-atom (atom {:selector-one {:value "1"
:name "name"
:options options}}))
(defmethod mutate 'selector/update-select-value
[{:keys [state]} key {:keys [value]}]
(inspect state)
{:value {:keys [:selector-one]}
:action #(swap! state assoc-in [:selector-one :value] value)})
the docs say that the :value has no effect on rerendering; not sure if this is your problem
if my memory serves me the component that calls the tx gets queued to re-render always, the rest are via read values in the tx
the reads I’m talking about are the read keys in the tx, e.g. [(todo/toggle) :todo/completed?]
When I merge in some new state, existing entities in the same table are being removed and replaced with the new. The refs to those removed items are still in the state, just no longer in the normalized table.
in on-change function just submitted the value to be changed, which makes me think ill need to pass this in if i want the parent to render. that or pass the keys to rerender to the child, which seems worse
https://github.com/cmcfarlen/om-next-tests/blob/gh-pages/src/om_next_tests/merge.cljs and the devcards here http://cmcfarlen.github.io/om-next-tests/#!/om_next_tests.merge
@anmonteiro: I have a bug that was introduced at commit a8559af 'OM-630: migrating tempids blows away component queries'
When using datascript at least, as state, and a custom :merge-tree, It introduced an error.
Seems it has to do with the change to use merge*
, and then immediately after you use merge
which is now a different function. I tried modifying the second merge
figuring you just forgot to change that one too, but that produces a different error. I don't understand enough of the internals there to help much more.
But I'm quite sure it has to do with reverting to a different merge, when a custom merge is provided.
@bplatz: it makes sense
no, I didn't forget to change to merge*
it's supposed to be cljs.core/merge
the problem is that we store the queries in the state map
when it's a datascript connection it doesn't know what to do
this will be solved once we add support to set-query!
for datascript users
Ok, I think I figured out my issue with the unexpected merge! result. If I make the :merge-tree fn be:
(defn my-merge-tree
[a b]
(if (map? a)
(merge-with merge a b)
b))
then I get the expected results. The default just does a single merge so the next state will overwrite the previous.