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

well, i guess the main point is the massively larger DB

the other option is to not normalize, and use computed props

are these my only 2 options?

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

across 30+ kinds of idents

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