Fork me on GitHub
#om
<
2017-06-16
>
wilkerlucio14:06:26

@ag you probably want a follow-up read after the mutation, something like (om/transact! ['(some/mutation :blabla) :read-key/after-mutation])

wilkerlucio14:06:44

om Om.next pure you might want to remove that key on the mutation so it get's loaded from the server after

uwo20:06:46

for those who have worked with reagent/re-frame, can you suggest tradeoffs that it makes or potential pitfalls of its approach? I prefer om-next personally, but my team mates are leaning toward reagent/re-frame.

naomarik06:06:55

uwo: I’ve made something using nothing but reagent then another app using re-frame/reagent and the latter was a lot easier to reason about. Everything works very well, the documentation on re-frame is extremely comprehensive and I’ve been able to mold my frontend to whatever I want and I’m extremely productive. The only thing that I’ve had annoyances with is dealing with complex relationships of normalized data, doing joins manually by filtering maps/vectors in subscriptions. I’m looking into re-posh now which seems to solve this.

tony.kay20:06:52

Has anyone use om/children to do React nesting in Om DOM? I cannot seem to figure out how to avoid react warnings on keys when I do it (so that it behaves more like the regular DOM elements).

tony.kay20:06:43

(b/ui-modal-title nil
          (dom/b nil " WARNING!"))
Tells me the dom/b needs a key, even though all ui-modal-title is doing is wrapping it in a div (with apply)

tony.kay20:06:07

(defui ^:once ModalTitle
  Object
  (render [this]
    (apply dom/div  (clj->js (om/props this)) (om/children this))))

(def ui-modal-title (om/factory ModalTitle {:keyfn (fn [props] "modal-title")}))

tony.kay20:06:57

I even tried changing the factory to a function that used apply on the om/factory. No dice.

tony.kay20:06:33

@uwo The trade-offs come when you try to deal with the overall data model as a (full stack) unified whole. You have to invent that with re-frame. You don’t with Om Next. Maybe try the Untangled Getting Started I just wrote as a way to see how Om Next (once you stack a few primitives on it) unifies the whole story. https://github.com/awkay/untangled/blob/develop/GettingStarted.adoc

uwo20:06:37

@tony.kay thanks. I’ve worked through a lot of untangled’s documentation and videos. It’s great stuff, and I’m personally sold. I just haven’t done any legwork on researching reagent and re-frame and their trade offs.

tony.kay20:06:30

The docs on re-agent are not that large…the questions to ask are: - How do I integrate that with a server? Search for the word “server” in the docs. Not a mention. Server-side rendering? - What the heck are “coeffect accretion and de-duplicated signal graphs.” and why do we want them? - How do I get organized around all of these detached query functions? - How do I find the code that goes with #(re-frame.core/dispatch [:delete-item 2486])? Joining this:

(defn items-view
  []
  (let [items  (subscribe [:query-items])]  ;; source items from app state
    [:div (map item-render @items)]))   ;; assume item-render already written
to the definition of :query-items means finding the binding that then names the function and then jumping to that. So, IMHO, the questions are mostly full-stack ones and ones of developer efficiency. When you look at the UI in Om Next, the data flow is purely query and transaction. Nothing else. I’ve demonstrated how mutations (with defmutation) can be made to be IDE navigable. If you’re using the default db format, then queries are largely satisfied with db->tree, meaning that you can trivially navigate the state model (which is normallized as well…so all you need to know is a component’s ident to find it’s state). The server integration in Om Next: requires almost no code and results in processing with identical look of that on the client: Process query/mutation notation. There’s not even much to write on the client (saying “:remote true”…wow, hard stuff). So, you have to understand a few things: - The normalized database model, and the Ident/IQuery functions that normalize/query it - Writing a parser that largely uses db->tree (In Untangled, you don’t even need to bother with that detail) - Writing mutations against a normalized database where everything is a get-in two levels away (update-in state-map [table id] operation) - React (which you need to understand for any of them) Compare that to needing signal graphs, co-effects, etc…and still not having a server interaction story.