Fork me on GitHub
#om
<
2016-02-13
>
iwankaramazow10:02:51

@anmonteiro: I just noticed with om/set-query! when you set the exact same query a component already has, there's a cryptic error #object[Error Error: Assert failed: Query violation, [object Object] reuses function etc.. Example: https://gist.github.com/IwanKaramazow/3047ae2f0a34733a10ab Not sure if this is valuable but maybe in the future users of Om Next should be aware that this ain't possible, i.e. a nicer error...

anmonteiro11:02:37

@iwankaramazow: not quite worried about this one, is there a use case for what you're trying to do?

anmonteiro11:02:53

does setting the same query a component have any purpose?

r0man12:02:21

Hello, I have a question regarding how to handle the result of remote queries and remote mutations in a send function. The server response of a remote query is a map, in which keys are the name of a query and the value the result of that query. This can look like this {:query-1 "result-1" :query-2 "result-2"}. When I pass this to the callback of the send fn it gets merged into my state as it is. The server response of a remote mutation is also a map, but looks a little bit different. The key is the name of the mutation and the value is another map with :keys and :result keys. Here's an example: {'my-mutation-sym {:keys [:reread-query-1 :reread-query-2] :result "result-of-my-mutation"}}. When I pass this to the callback of the send function it will also get merged into my state. But when doing this the state will contain keywords (result of queries) and symbols (result of mutations) as keys. So my questions is, is this the intended behaviour of the callback function? Am I allowed to transform the server rersponse of a remote mutation before passing it to the callback (like does the callback expect the :keys and :result keys)?

r0man12:02:56

My send function looks like this at the moment:

iwankaramazow13:02:59

@anmonteiro: Not really a use case. Just encountered this one while implementing routing. Some child-routes are pure functions, whenever a child is a pure function I om/get-query the RootView. In some situations this would result into replacing the query with its own query.

iwankaramazow13:02:53

Solved it with a simple equality check.

iwankaramazow13:02:01

More of a problem on my side of the code actually

anmonteiro13:02:35

Right. Om thinks you're stealing the query because you're setting a component's query with a component's query

anmonteiro13:02:42

which in fact is your own

anmonteiro13:02:08

This could probably be addressed but I'd say it's not a priority

geraldodev13:02:21

@anmonteiro om/get-query wiping ^:query-root is considered a bug ?

anmonteiro13:02:17

@geraldodev: not sure about that one. wrt to what you linked regarding process-roots yesterday that's something which is not currently supported

geraldodev13:02:01

@anmonteiro: have you seen the defui NestedComp snippet ? Because I think it proves otherwise. In terms of query depth [{:a-thing [{:another-thing [:foo]}]}] and [{:a-thing [({:another-thing [:foo]} {:param :one})]}] are equal, are not ? Because with the 1st process-roots works, and the second it does not. and that is not process-roots fault, it's get-query that is wiping the ^:query-root metadata

anmonteiro13:02:41

I have. As I told you, process roots doesn't support sub-roots

geraldodev13:02:16

The use case I'm using is very simple: (om/get-query (om/app-root reconciler)) [{:grid [({:cliente [:id :nome :endereco :bairro :cep :cidade :versao]} {:pagina 1})]}] The grid part is local and is about the how the data is fetched, the {:cliente } part is what is meant to be sent to the server. Sorry to bother with this, but the param passing is important, otherwise I can't paginate. Shall I rewrite the query on my own in this case ?

thiagofm14:02:59

I have a setInterval in a componentWillMount, how do I clear it up in componentWillUnmount? setInterval returns an id, but then I have to pass it to componentWillUnmount, is thre any easy way to achieve it?

isak15:02:01

@thiagofm: you could try

(set! (.-timeoutId this) (js/setTimeout ...))

thiagofm15:02:01

I made it! 😄 I had to save the id setInterval returns and load it in componentWillUmount

anmonteiro20:02:23

@geraldodev: seems like a bug

seancorfield20:02:39

Since the presence of #C0DT1AZD3 seemed to be confusing people and it was getting no traffic, I archived it.

akiva20:02:49

Thank you.

anmonteiro21:02:38

@dnolen: as per @geraldodev 's report, bind-query is losing query metadata such as :query-root which makes process-roots unusable for queries with parameters

dnolen21:02:40

@anmonteiro: file an issue, the more information the better

anmonteiro21:02:49

@dnolen: will do.. it seems like the fix would be to walk the query ourselves

anmonteiro21:02:09

clojure.walk doesn't preserve the metadata

dnolen21:02:32

@anmonteiro: hrm it should but maybe there’s a problem somewhere

anmonteiro21:02:44

I've confirmed it

anmonteiro21:02:34

@dnolen: also the Eastwood linter re-implemented walk because of this too. from the docstring: walk was copied from Clojure 1.6.0, and then modified to preserve metadata on all sub-values of the input form that have them.

dnolen21:02:46

@anmonteiro: hrm wow, yeah for some reason I thought Clojure walk preserved meta. Happy to see us use a version that fixes that problem.

anmonteiro21:02:13

@dnolen: happy to submit a patch.

dnolen21:02:38

patch welcome

anmonteiro21:02:45

you didn't mean to re-implement walk ourselves right? just to be clear

anmonteiro21:02:02

I'm sure custom walking is enough since it's only used in this case

dnolen21:02:07

whatever’s simpler - no need to go that far

futuro22:02:40

Is there anyway to debug om next?

futuro22:02:55

adding a query to one of my components is causing it to fail to render, and I have no idea why

cjmurphy22:02:48

You could see what the props received by the component are.

cjmurphy22:02:30

They must have changed, hence doesn't render properly.

futuro22:02:56

@cjmurphy: I think it's because one of my read functions returns an empty map for {:value {}}

futuro22:02:28

I got lucky while commenting out different aspects of the component in question, and having a query stopped it from rendering

cjmurphy22:02:24

Cool - and that bad read would mean bad values for props, hence bad render.

futuro22:02:55

yeah, that makes sense

futuro23:02:09

What is the point of IQueryParams?

futuro23:02:40

I'm trying to wrap my head around them, but I'm not really grokking it

hueyp23:02:51

you might have a query which supports pagination … as you set page, you update IQueryParams

hueyp23:02:57

other use cases as well

hueyp23:02:02

using IQueryParams to set the query