Hi all, what’s the idiomatic om.next way to represent an entity in many ways? Given an person entity, one might want to display this person in a list or as a card, or show more or show less. Should one just make one component which accepts a display-mode argument? Or should there be several components that declare their own queries and render their own way? If so, which one should declare the ident? Should they all declare idents? etc...

@levitanong I think that will depend on your specific use-case, there are no general rules like that. In general, follow react best practices. Om.next just helps you decouple your state management and update components more efficiently when that state changes. Idents refer to specific values in the state, either at the root or within an om.next table (part of the normalization process). If you're component relies on a specific entity, it's good to declare an ident so that om can update it efficiently if that state changes.

@danielstockton I think my issue is more related to om.next’s queries and normalization, but I’m having a hard time putting it down on words. Will think more on how to phrase it

It helps to put it into plain react context imo. In react, everything gets passed down from root. It's the same in om.next, all component queries must compose to root and then om passes everything down for you. React has forceUpdate and shouldUpdate to re-render individual components. Om leverages the queries to help with this, needing nothing special on your part.

It's just a way of declaring what data each component needs, rather than explicitly passing everything down, and lets you decouple the state management from writing components.

@danielstockton would you say that it’s perfectly fine for the UI tree to have two slightly different lists of the same group of things?

so like, one list of users with a certain set of fields, and then somewhere else, the same list of users with a different set of fields

Sure, if that leads to a good UX for whatever you're trying to do. There are no hard rules like that, as long as you understand your own design goals and the trade-offs involved with implementing them.

:thinking_face:

Om queries encourage each component to ask for what it needs, nothing more. It can help if the queries compose in such a way that you don't have to fetch the same data more than once from the backend in terms of performance, you can think about that.

Also, it's always the parent component query that includes the queries of the children with (om/get-query Component). If you have a parent component that is shared by these two lists, you might want to think about making their queries the same (including all data needed for both lists), rather than having two similar but slightly different queries that don't compose on the backend.

They don't have to be the same actually, you can compose them into one 'merged' query in the parent, using the full power of clojure..

Thanks for the answer, @danielstockton

@levitanong @wilkerlucio made a good point in the replies above, you shouldn't really merge queries on the frontend.

yeah, you lose metadata

oh! threads exist

thanks @wilkerlucio

So om/force is working for me, mostly. It fetches data and the data is merged into the app-state. But randomly doesnt trigger re-read. As cmcfarlen suggested yesterday, this is my read

(defmethod read :search/search
  [{:keys [state ast target] :as env} k params]
  (if target
    {:remote (assoc ast :params (get @state :search/queries))}
    {:value (get @state k)}))

(om/transact! this [(list 'filter-statuses!
                              {:status status-buffer})
                        (om/force [:search/search])
                        :search/search])

btw om/force seems to only work for keys within vector, causing the response to be {[:search/search] [....]} instead of {:search/search [...]}, this could potentially distrupt the read the reconciler is attempting to initiate?

yes seems to have been the case, the spirit of the rubber duck came over me.

static om/IQuery
  (query [this]
              [[:search/search '_]
              [[:search/search] '_]
              ...and more... ])

nonetheless, could be an occacion to open ticket for om/force so that it can accept keywords as well as vectors as argument.

@hlolli Maybe that's why it never worked for me. In any case, if true, the documentation needs an update: https://github.com/omcljs/om/wiki/Documentation-(om.next)#force

ok let me double check, the documentation seems to indicate the opposite.

yup I was right, only keywords throws me exception

cljs$core$ExceptionInfo
cause: null
columnNumber: undefined
data: cljs.core.PersistentArrayMap

Looking at the source, it seems like the documentation is correct and it should be a keyword, because transact! accepts keywords and force simply adds some metadata to those keywords.

could it be a thing with namespaced keywords.. 😕

Doubt it, I definitely tried force with a namespaced keyword and it didn't throw an exception, although I seem to remember it didn't have the desired effect of calling a remote read either. Don't have a specific example to test at the moment.

ok, let's keep an eye on this function then

@levitanong The OmNext UI query tree is designed to handle lots of duplication in a clean way- The job of the parser functions is to resolve the impedance mismatch between the query tree and the data model of the app-state, and the latter should be free of data duplication. If you have data that you need to display in 3 different formats, create three different ways to query the data and don't be afraid to let data duplication happen.

awesome, that’s comforting to know @drcode