Fork me on GitHub
#om
<
2016-06-22
>
jimmy02:06:25

@anmonteiro: I just tried compassus but it seems there is some uncaught problem regarding normalize data from remote. I compose a gist here: https://gist.github.com/rhacker/a362e32dc80163c590eaaadbd2b3aa7b The problem I found is the normalize* function from om next doesn't iterate through the root-query of the component so the data from remote is not normalized. It would be great that you take a look at it. thanks

selfsame04:06:06

or was there a way to join [* {:foo [*]}]?

anmonteiro13:06:10

@nxqd: I don’t see a bug

anmonteiro13:06:23

the docs might need some clarification, though

anmonteiro13:06:27

you’re sending a query to the remote with :notes as the key

anmonteiro13:06:43

IMO, the remote should not have knowledge about the routes on the client

anmonteiro13:06:50

so you might want to return a modified AST

anmonteiro13:06:12

such that the key on the remote is :notes/list

anmonteiro13:06:33

you’re also not passing the query to the callback in send

anmonteiro13:06:45

you need to do that if you want the remote response to be normalized according to the query that was sent

jimmy14:06:11

@anmonteiro: this is the second attempt based on your suggestion ( didn't know what om have a second query on cb function, thanks ! ) https://gist.github.com/rhacker/a362e32dc80163c590eaaadbd2b3aa7b/revisions It still has one problem, I've tried to figure out but not sure what's wrong is that when I first change the route to users, the new users is not re read ( this sounds familiar .. ), the second time it's there

anmonteiro14:06:51

should just be st @state

anmonteiro14:06:44

@nxqd: I’m actually going to consider your use case

anmonteiro14:06:57

if you wanna try master in a few minutes, I’ll ping you

jimmy14:06:27

sure, it would be great

anmonteiro14:06:11

just need to make sure it doesn’t break things for other use cases

anmonteiro14:06:45

it’s what I’m changing to accomodate for your use case

jimmy14:06:18

ok, doing it now

jimmy14:06:20

@anmonteiro: it works flawlessly. And regarding the my last attempt, I still don't understand why it doesn't reread the first time I change the route to users.

jimmy14:06:19

should I add the example to the devcards as well ?

anmonteiro15:06:21

@nxqd: sorry what attempt? I might not have seen that, care to link again and explain what's not working?

danburton18:06:01

Is it bad practice to call om.next/transact! on a reconciler from within the mutate function for that same reconciler? In other words, is it bad practice for one transact! to trigger another?

danburton18:06:29

Basically I am trying to find a way around using computed params, because it is tedious to pass them down through a tree of components. So when a leaf component calls (om.next/transact! this '[(leaf-foo!)]), it can just trigger (om.next/transact! reconciler '[(foo!)]).

cmcfarlen19:06:57

@danburton: I wrote a utility fn that takes a factory and a component and returns a new factory that merges in the given component's computed props with those passed to the new factory.

cmcfarlen19:06:09

It takes some of the tedium out of managing computed params

danburton19:06:23

I've contemplated that as well. I like that it simplifies the call site.

cmcfarlen19:06:53

(defn merge-computed-factory
  "return a new factory that will merge the given map of computed into any that might be passed in through props."
  [f computeds]
  (fn [props & children]
    (f (om/computed props
                    (merge (om/get-computed props) computeds)) children)))

(defn forward-computed-factory
  "return a new factory that will merge in computeds from the given component or props"
  [f this-or-props]
  (merge-computed-factory f (om/get-computed this-or-props)))

iwankaramazow19:06:45

or you might write helper functions to compose :action in the mutations

anmonteiro20:06:58

@danburton: there’s also nothing stopping you from running 2 mutations in one transaction: (om/transact! this ‘[(leaf-foo!) (foo!)])

danburton20:06:15

The point of one transaction calling the other is so that the second one can transact on the reconciler (as supplied in the env argument of mutate), rather than on this.

anmonteiro20:06:56

@cmcfarlen: looking at your Compassus gist right now. I’m not too keen on adding what you suggest. Looking into an alternative way to do what you want with the constructs that are already in place

cmcfarlen20:06:43

@anmonteiro: ok. My goal here is to be able to support stable urls into the app. I tried briefly to get the indexer to give me the component for the current route and set the params that way, but it wasn't cooperating.

anmonteiro20:06:27

@cmcfarlen: the first alternative is just changing shouldComponentUpdate and calling set-query! in componentWillUpdate too

cmcfarlen20:06:19

@anmonteiro: ok, I'll give that a try. Any caveats overriding shouldComponentUpdate? Do I need to also call the om.next version?

anmonteiro20:06:01

@cmcfarlen: another alternative is to just keep the params stuff in the app state and don’t mess with it in queries

anmonteiro20:06:55

@cmcfarlen: example sCU:

(shouldComponentUpdate [this next-props next-state]
    (let [next-props (om/get-props next-props)
          next-props (cond-> next-props
                       (instance? om/OmProps next-props) om.next/unwrap)
          [_ current-id] (ffirst (om/props this))
          [_ next-id] (->> (pushy/get-token history)
                        (bidi/match-route bidi-routes)
                        :route-params
                        first)]
      (println 
          current-id next-id)
      (or (not= (om/props this) next-props)
          (not= current-id next-id))))

anmonteiro20:06:53

@cmcfarlen: sorry for the spam. Better yet, without needing to mess with sCU, just set-query! both in componentDidMount and componentWillReceiveProps

anmonteiro20:06:03

makes it really concise

anmonteiro20:06:15

(componentWillReceiveProps [this next-props]
    (om/set-query! this {:params (:route-params (bidi/match-route bidi-routes (pushy/get-token history)))}))
  (componentDidMount [this]
    (om/set-query! this {:params (:route-params (bidi/match-route bidi-routes (pushy/get-token history)))}))

cmcfarlen20:06:21

@anmonteiro: ok, cool. Thanks! I'd like to stick to params as the app I want to add routing to already uses them so it would be easy to hook up the url params.

anmonteiro20:06:59

@cmcfarlen: so this componentWillReceiveProps thing should be just what you need

anmonteiro20:06:53

@cmcfarlen: OK to close the Compassus issue?

cmcfarlen20:06:47

@anmonteiro: yes sir! Thanks for your help.

anmonteiro20:06:00

happy to help, glad you’re trying Compassus out!

jimmy23:06:35

@cmcfarlen: just a bit of exp, I have done the same thing to update the params using set-query! to make sure it in sync with the url as well. But you would love to keep params within app-state since you can control the rerender better 🙂