This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-27
Channels
- # admin-announcements (1)
- # aleph (3)
- # beginners (72)
- # boot (67)
- # braveandtrue (1)
- # cider (17)
- # cljs-dev (8)
- # cljsfiddle (2)
- # cljsjs (1)
- # cljsrn (2)
- # clojure (19)
- # clojure-greece (1)
- # clojure-russia (42)
- # clojurescript (15)
- # core-logic (10)
- # cursive (6)
- # datomic (2)
- # hoplon (349)
- # kosmos (3)
- # lein-figwheel (3)
- # om (52)
- # onyx (3)
- # overtone (1)
- # parinfer (11)
- # proton (11)
- # protorepl (3)
- # reagent (29)
- # ring-swagger (2)
- # spacemacs (1)
- # testing (3)
- # uncomplicate (1)
Hello, was wondering on the off chance if anyone felt like checking out my question on SO: http://stackoverflow.com/questions/36246648/om-next-read-multi-fn-not-being-called-in-second-level-join-query-ast-not-parse
@donavan: try using db->tree
instead of (into [] (map #(get-in st %)) (get st key))
Ah! Merci... My understanding of what's going on is the problem then! Though now I see another issue... do ids need to be unique across all react components? Unlike, say, SQL where an index is unique per table?
Yes need to be unique across all components. Or that's what I've always assumed since reading the Kanban demo. Your initial data for instance probably has lots of say {:id 10}. The algorithm that gets your data normalized in the first place would certainly have an easier job if all the numbers were unique. But I'd be keen to know the real reasoning behind this requirement.
It seems to me to be a React requirement . I get a lot of react.inc.js:18780 Warning: flattenChildren(...): Encountered two children with the same key, '$1'. Child keys must be unique; when two children share a key, only the first child will be used
. One for each key that is duplicated across sub-components even though they are of differing component types. (edited grammar and removed backticks from error msg)
I missed the word React before. So here: (def simple-svg-tester (om/factory SimpleSVGTester {:keyfn :id}))
, :keyfn
is what React gets.
But React does not need them to be unique across your whole app-data - that's an Om Next default db format requirement.
It does seem to be a React requirement (caveat: I'm learning React via Om!) http://facebook.github.io/react/docs/reconciliation.html#keys Though they need to be unique amongst siblings, which is exactly what I did as I worked through my dummy data, each sibling (of differing component types) got the same key id from 1...n. I was thinking like SQL indexes, i.e. unique per table/type! It seems to me that Om doesn't have the requirement because things are identified by [:key id]
and not just by id
. Though you still can't have the same key (component type) and id as then the the app state map will eat all but the last one when assoc'ed in (if that's how it adds to the normalised map, that is)
in my experience it works the same way as react, where the id is prefixed with a component name, like how you described
is there an easy way to add to the normalized app state? right now I'm adding a row to the db and then adding an ident elsewhere in two separate swaps
(defmethod mutate 'people/add-person [{:keys [state ast]} _ params]
{:action (fn []
(let [id (random-uuid)]
(swap! state assoc-in [:people/by-id id] (merge params
{:db/id id}))
(swap! state update :people conj [:people/by-id id])))})
@frank: you definitely don't need to swap!
twice
(swap! state
(fn [st]
(let [st' (assoc-in st [:people/by-id id]
(merge params {:db/id id}))]
(update st' :people conj [:people/by-id id]))))
the two operations are still required, though
cool thanks @anmonteiro !
@haywood, I just changed all my dummy data keys to be unique. It all renders correctly now. I looked at the React IDs and all the components have a $null
in them, should they have the component name in them as you say?
looking at the react id for a nested element in my toy app looks like reactid=".0.1.$tiles$core$Grid_[=2tiles/grids 3].$tiles$core$TilesRow_[=2tiles/grids 3 =2rows 0].$tiles$core$Tile_[=2tiles/grids 3 =2rows 0 =2tiles 6]"
@haywood: looks OK to me
are there any 'easy' tasks that need to be done in om.next, that a mild beginner could tackle?
I'd love to contribute @anmonteiro
@haywood: there is something
there's this macro, invariant
we have talked about using it more in the code, where it makes sense, just like React does it
to help catch rookie mistakes
things like validating query grammar
detecting if queries are correctly composed
those are all useful things
@donavan: Those $null mean React is not able to get a key to use for your component. This is not particularly a problem unless you have many components together at the same level. But it is possible to have no $null
for any components - a clean slate. React needs to know the function (example: {:keyfn :id}
). Then the function needs to be in your query - i.e. be what is passed in as props.
@cjmurphy: @haywood Ok, I do have {:keyfn :id}
as the second arg to om/factory
... I'll have to have a look in the morning. Thanks for all the help.
for now I have (om/set-query! this {:params {}})
in my component to redo all the sends
@tomjack: using websockets, I suppose?
you can still push it to the edge by polling the REST somewhere and calling om/merge!
on the results
yeah, thinking about that. I guess I need to keep track of "which data still needs polling" myself if I want to stop polling when that data is no longer needed
toy example: /lists
returns todo list ids, /lists/:id/todos
returns a list's todos. we should only poll /todo-lists/:id/todos
for those lists which are currently being rendered