This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-31
Channels
- # architecture (1)
- # aws (23)
- # beginners (13)
- # boot (18)
- # cider (5)
- # clara (1)
- # cljs-dev (22)
- # cljsjs (9)
- # cljsrn (28)
- # clojure (120)
- # clojure-canada (12)
- # clojure-dev (6)
- # clojure-italy (4)
- # clojure-korea (1)
- # clojure-russia (18)
- # clojure-sg (8)
- # clojure-spec (45)
- # clojure-uk (12)
- # clojurescript (240)
- # component (4)
- # cursive (17)
- # datomic (91)
- # editors-rus (4)
- # figwheel (2)
- # flambo (6)
- # hoplon (163)
- # instaparse (6)
- # jobs (1)
- # leiningen (2)
- # luminus (5)
- # om (22)
- # om-next (2)
- # onyx (35)
- # perun (15)
- # play-clj (1)
- # protorepl (4)
- # re-frame (106)
- # reagent (4)
- # ring (106)
- # schema (1)
- # spacemacs (17)
- # untangled (40)
- # yada (14)
does om have any kind of caching story for denormalization?
@ethangracer you can memoize db->tree
@anmonteiro cool thought, thanks
Hello, om.next idiom question here.
I’m trying to pass a UI state (stored in app-state, like :current-tab
, or something) to a component (let’s say Student
). As I understand it, I probably shouldn’t place :current-tab
in Student
’s query, as it isn’t a part of Student
-ness. It’ll probably mess up the normalization, etc…
So my question is, where is the appropriate place to put it? My guess is via computed
.
i.e.
(student-view (om/computed student-props {:current-tab current-tab}))
The above works fine for me (so far), so I guess I’d like to know if my approach is idiomatic, and if it isn’t, what is the correct way?@levitanong it looks to me that Links are what you want https://github.com/omcljs/om/wiki/Thinking-With-Links%21
Component render
functions shouldn’t be worried about the data that its child component needs
only the parser should worry about that
calling db->tree
on a query that has a link will resolve the link and include it properly
@anmonteiro Thanks! Will take some time to read this.
@anmonteiro the issue that I thought had to do with denormalization actually has to do with path-meta. it is increasing my runtime by 50% for recursive reads
I can send a cpuprofile if you’re interested
@ethangracer hrm path-meta
will always have to walk your data structure to tag it with the appropriate path
so that om can index?
not sure I understand, if I’m generating props why do I need all that metadata
full-queries, indexing, etc
wondering if it’s possible to reimplement path-meta as a tail recursive call but it doesn’t look too promising
@ethangracer path is also a big part in incremental rendering, btw
So the om components depend on meta data in the props to help with incremental rendering?
I’ll have to try memoizing it, not sure it’s going to make much of a difference though. not seeing a lot of overlapping subproblems, unless i’m missing something
thanks