Fork me on GitHub
#om
<
2016-11-29
>
danielstockton12:11:01

@anmonteiro should i be able to call compassus/set-route! on the reconciler in merge?

danielstockton12:11:37

It prints redirecting to... but nothing happens

danielstockton12:11:35

This is for redirecting after logging in, and also redirecting unauthorized reads to /login

danielstockton15:11:30

If an update happens to my app-state causing the root component to re-render, does this trigger re-reads of the whole query or just parts of it that were updated? I'm having trouble working out why I get two identical remote reads happening in quick succession.

danielstockton15:11:43

It happens each time I change route

haywood16:11:21

question: I couldn't figure out how to use db->tree without finding an example usage on the net and was wondering if a change like this would be acceptable:

haywood16:11:46

I renamed ref to app-state, and created another arity for more basic usages e.g. (om/db->tree [:people] app-state)

peeja17:11:41

@haywood I think calling that app-state is a bit too concrete. It's not necessarily the state of an app, it's just a map you can look up idents in.

peeja17:11:15

It's good to point out in the docstring that that's usually the root of the app state, but I wouldn't rename the argument

haywood17:11:47

ok yea that makes sense, would still prefer if it was something a bit more descriptive, I couldn't figure out what a ref map could be. map-with-idents

haywood17:11:22

I'm basically the lowest common denominator, so bear with me 😛

ag18:11:04

Hey guys, quick question. When having a hierarchy of components, I find myself using this pattern over and over:

(render [this]
   (let [props (om/props this)]
    [:div
      (ui-foo-component props)
      ((bar-component-fn "bar") props)
      ;; bar-component-fn returns a factory
      ]))
So, if I have to pass props all the time, maybe there's a way to reduce this boilerplate? Maybe some kind of macro. e.g. (ui-> bar-component "bar")

ag18:11:50

(macro that takes a factory instance, or a fn that returns one, some arbitrary params and calls it passing (om/props this)?

haywood19:11:29

is this om.next?

ag19:11:24

of course

haywood19:11:33

just curious, you pass the entire props through a lot?

ag19:11:07

hmmm, I guess I do most of the time. And then filter out whatever is needed down the chain

isak19:11:09

are renders triggered through om.next/update-state! handled sync or async?

isak19:11:03

looked at the code, and looks like just async, unless there is no reconciler, which looks like can happen if you dont use add-root!

haywood20:11:10

[:current-user '_] works

drcode20:11:42

@haywood Not sure if that's possible- The way I usually handle this situation is to just make the :current-user reader just access the global state directly, so I can just write [:name :email {:current-user [:email]}]

drcode20:11:44

@haywood My own rule of thumb is "Keep the queries simple, put the complexity in the parser reader methods"

drcode20:11:07

@haywood (The downside of this rule of thumb is that eventually you have stuff in the parser functions that prevents tree->db from working and then you have to write your own merge/migrate functions for server syncs)

haywood20:11:08

since [:top-level-key _] is allowed I wonder how hard it would be to add that bit of extra functionality

haywood20:11:05

I'll mess with it, but until then I can use your suggestion @drcode thanks for the reply!

haywood21:11:19

normalize* is a beast!