This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-11
Channels
- # bangalore-clj (1)
- # beginners (24)
- # boot (134)
- # boulder-clojurians (2)
- # cider (3)
- # cljs-dev (2)
- # cljsjs (44)
- # clojars (9)
- # clojure (60)
- # clojure-greece (2)
- # clojure-quebec (1)
- # clojure-russia (44)
- # clojure-spec (15)
- # clojure-uk (1)
- # clojurescript (37)
- # core-matrix (1)
- # datomic (7)
- # emacs (1)
- # hoplon (154)
- # liberator (3)
- # mount (2)
- # om (20)
- # onyx (2)
- # pedestal (3)
- # planck (12)
- # re-frame (26)
- # reagent (32)
- # uncomplicate (4)
Thanks @anmonteiro, opened an issue and made an reproduction with devcards (should probably be a test). I think the solution is to just provide a default getInitialState
.
I’ll work on that.
I’m also interested to hear your thoughts on om/computed
props. It seems the React ecosystem just passes callbacks and other computed things through props. I’m not yet sure what computed
gives us with Om yet, but would it be beneficial to support merging computed
values back into the react component props?
@gardnervickers: awesome, I'll look into it soon if you don't get to it first :-)
Thanks!
So om.next/computed
's purpose is to make sure that you can pass props that the parser doesn't give you (such as callbacks like you said) and that aren't meant to change through the lifecycle of an application while being able to do incremental rendering
ahh ok
So if om.next
doesn't re-render from root, you possibly wouldn't get the computed props that you merged to the queriable props in the parent
Exactly because the re-render step wouldn't start at that parent
@gardnervickers: it makes total sense to merge them into React's raw props though in omify
's case
So that probably deserves another separate issue
I’ll open one
Thanks a lot!
so i'm writing a UI for seaching our data in om.next, like any typical search it has search results, one per row in a table, and then each row with several columns, naively I could do have components Search, SearchResult, but i have 5 different kinds of search results, so this leads me towards union queries and a ton of different components, I could normalize everything down to the column level, UserSearchTitleCol, UserSearchCompanyCol, and have idents for each column, so this is both a ton of code, and the om DB has like 30+ new entries at the root level, one for each column, and more
the massively larger DB seems a bit of a pain because i have to garbage collect all the time whenever a new search query is run
The other challenge with option #1 , is that UserSearchResultRow would have a query like {:title (get-query UserSearchTitleCol) :company (get-query UserSearchCompanyCol), and so on ... } and that means the data that flows into UserSearchResultRow needs to look like {:title {partition of the search result data that pertains to title} :company {partition of the search result data that pertains to company} } and that's not how it looks in the backend it's just documents , so I would need to use process-roots to manipulate the data