Fork me on GitHub

Hi all, what’s the idiomatic 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. 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 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’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, 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.




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..


danielstockton: this may not be a good idea, merging queries would make Om lose track of which component points to what, because you lose the meta (you can't have 2 different metas for the component definition on the same query), and that affects the incremental rendering and may cause you "Can't find path for component..."


this is why is probably preferred to use multiple paths on those situations, my recommendation is to use "placeholder nodes", nodes that on the server deepen the query level but stay at the same logical place


Good point, I've hit that 'can't find path for component' problem before.


example: [{:ph/thing [:name :age]} {:ph/thing-2 [:name :other]}]


and on the server you can read for ph namespace and do the magic 🙂


That's a good idea, thanks 👍


no problem 🙂


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


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)}))
and this a typical transaction that triggers it
(om/transact! this [(list 'filter-statuses!
                              {:status status-buffer})
                        (om/force [:search/search])
I duplicate :search/search to re-enforce the re-read, but I may be tackling this from the wrong direction, is it maybe possible to tell the reconciler to do a re-read when the response arrives/after app-state merge?


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... ])
looks like the reconciler wont know that :search/search needs re-read when it gets response with [:search/search] hence, goes looking for forementioned query.


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:


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


yup I was right, only keywords throws me exception

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