Fork me on GitHub
#om
<
2016-01-13
>
featheredtoast01:01:09

om.next newbie question: Can anyone point me in the right direction for doing updates for aggregate components? Am confused as to how to get an additional component to sum (and update) up multiple pieces of the app state. https://github.com/featheredtoast/hello-om-next/blob/master/src/cljs/hello2/core.cljs

featheredtoast01:01:25

--sample provided is my attempts at getting something to display a running total of all counters. I am able to update state for the aggregate provided by including ':counter' in the om/transact! but that appears to also re-render all other counter components as well. I'm curious as to how you guys would deal with this. Would I hold calculated values in the app state as well, and re-calculate inside the transaction? Making progress on understanding om and its models, but maybe not 'getting' it just yet.

hugod02:01:59

I’m trying to work out why my (child) component ends up reading it’s own local query, rather than using its ident. The component in question is in a react native data-source, in a ListView. full-query doesn’t seem to use ident, and returns the component’s local query so I think I’m mis-understanding how this should be working.

zalky05:01:06

Hi all: I seem unable to send to remotes from anything but a root query. I encountered this in my own experiments, but I can reproduce the problem by making a very minor modification to the working AutoCompleter tutorial. If I add a very trivial Root component (line 77:84) and a very trivial matching read (line 31:33), the :send function does not get invoked for the child autocomplete. Here is the sample code: https://gist.github.com/zalky/573d2eb12ae3f6fcb2d3.

mudphone05:01:32

@juhoteperi: thanks for your help yesterday, turns out I needed to bump Om to alpha 28 to get advanced optimizations to work. Also, understanding how CLJSJS deps work is nice simple_smile

jimmy08:01:50

@zalky: it's true. I will hit the Root component first and send the query right there. But the thing is you can provide additional {:value } to get the cached value.

tap09:01:47

Can someone explain to me how (increment) turns to ’increment symbol in this example? https://github.com/omcljs/om/wiki/Quick-Start-(om.next)#components-with-queries--mutations

tap09:01:51

(increment) in render function and ’increment in mutate function

rburns09:01:15

isn't the enclosing vector quoted in the render function

tap09:01:11

Yes, it’s quoted. I believe I’m really missing something but why can’t we just write (om/transact! this '[increment])? (I have tried that and it causes error)

tap09:01:32

‘app/increment here makes sense to me but it’s a little different with multi-method https://github.com/omcljs/om/wiki/DataScript-Integration-Tutorial#integrating-datascript

(om/transact! this
                   `[(app/increment ~entity)])

rburns10:01:07

I think that has to do with the query syntax the parser expects. you can see the mutation syntax in the examples here https://awkay.github.io/om-tutorial/#!/om_tutorial.D_Queries

tap10:01:21

I see. The overall tutorial also looks helpful in general. Thanks

geraldodev10:01:18

@hugod https://gist.github.com/geraldodev/fd6c61eac7ab4b37c616 I ended up with the entire state on nested component, and figured that was because (get-in {} nil) returns the entire thing. also I was caught by the fact that if a nested component has a value and afterwards its read function returns nil the value remain untouched , so what I really needed was to return an empty map, so I made get-in-link.

dnolen14:01:10

@tony.kay: looking at your PR today, have a couple of brief questions

anmonteiro14:01:28

@dnolen: something came to mind relating to tempids: it seems to me that, due to how the reconciler expects an :id-key, you can only ever have one entity in an Om Next app merging tempids successfully

anmonteiro14:01:58

(with the provided default implementations, that is)

dnolen14:01:53

@anmonteiro: if you mean a tempid can only become one real ident - yes

dnolen14:01:09

but this inflexibility doesn’t seem like a problem to me at the moment

anmonteiro14:01:37

more, if you normalize your state in the manner that you use in most tutorials (have an :id key in the state, but normalize it to e.g. [:person/by-id :id] ), it won't get properly merged

anmonteiro14:01:52

because if your reconciler's :id-key is :person/by-id, the merge will write a new key :person/by-id in the, say, Person entity, and the tempid will still be there in the original :id key

dnolen14:01:47

@anmonteiro: that’s not how the merge ident logic is supposed to work - could be a bug or you are reading it wrong

dnolen14:01:57

there’s code to replace the old thing

anmonteiro14:01:57

I've tried it with a simple example

dnolen14:01:14

right a naive thing sure

dnolen14:01:30

but the server should be returning the new values for stuff anyway

dnolen14:01:32

tempid migration is really about fixing all references

dnolen14:01:36

you have to deal with fixing the data

anmonteiro14:01:23

@dnolen: right, I'll play with it again given this new information, thanks for clearing it up

dnolen14:01:34

pretty sure that’s what I added :id-key in the first place

anmonteiro14:01:30

@dnolen: not sure we're talking about the same thing, but I need to dig deeper before I can confirm any suspicions

anmonteiro14:01:04

will only have time later, so I'll get back to you on that

dnolen14:01:16

:person/by-id isn’t :id-key

dnolen14:01:28

:id-key should be the universal identity property in your application

dnolen14:01:32

i.e. :id or :db/id

dnolen14:01:25

sorry I just misread what you were saying above

anmonteiro14:01:35

@dnolen: that makes much more sense

anmonteiro14:01:48

and that was indeed my first approach when I was trying this out

anmonteiro14:01:22

I either couldn't make it work because I was doing it wrong, or there's some subtle bug. I'll confirm it later today and let you know

dnolen14:01:33

cool, thanks

anmonteiro14:01:48

(most probably something wrong on my part, but still...)

dnolen14:01:47

@anmonteiro: we don’t have an :id-key test - happy to have one that confirms this thing actually works simple_smile

adammiller15:01:00

unless i’m misunderstanding something that’s exactly how my sample worked for tempids @anmonteiro: https://github.com/akmiller78/tut-omnext-tempids/blob/master/src/om_a_1/core.cljs

anmonteiro15:01:57

@adammiller: will look into it later, thx

griff15:01:59

Can anybody help me? I am playing with the om next tutorial and trying to add a modal dialog component but for some reason the first transaction doesn’t trigger a rerender but all transactions after that do. And I have no idea why. The code is here: https://gist.github.com/griff/e2bd4b41bc9f3fee66fe

adammiller15:01:59

@griff i haven’t pulled it down and tried it yet, but just glancing at the code I’d suggest adding the keys you want re-read at the end of your transact call: https://github.com/omcljs/om/wiki/Documentation-(om.next)#transact

anmonteiro15:01:41

@griff: what do you mean by the first transaction?

anmonteiro15:01:49

I'm getting what I think is the expected behavior

anmonteiro15:01:30

(after deleting an unexpected (get test) in the query of the Person component)

griff15:01:24

The first time i press a button after reload nothing happens (other than the console telling me that the transaction was made). Second time i press the button and whatever action I do after that it rerenders just fine.

anmonteiro15:01:17

@griff: not able to reproduce

anmonteiro15:01:50

anyway, if your problem happens with reloads, maybe you should write your code to actually be reloadable

anmonteiro15:01:08

e.g. defui ^:once actually exists

anmonteiro15:01:16

also defonce your reconciler should help

anmonteiro15:01:47

the latter definitely being the more important one

jimmy15:01:50

Hi guys, is there any function that we can evaluate props of a component based on its query ? To test in repl

tmorten15:01:01

Morning all! I must be missing something with how the reconciler is merging my remote data? It seems to me that if I have normalization activated, every remote call replaces any of the :by-id tables that are in my state instead of merging them...I'm guessing this is by design?

jplaza15:01:25

@griff: @anmonteiro is right, I had the same issue when playing with Om

tmorten15:01:17

@nxqd: One of my approaches has been to run the query through the parser and check results. i.e. (parser {:state app-state} (om/get-query RootView)). I can do this at REPL quickly

tmorten15:01:52

@nxqd: If you need to change a parameter for a component on screen you can use the (def root-view (om/class->any reconciler RootView)) (om/set-query! root-view {:params {:id 10}})

jimmy16:01:14

thanks for helping

anmonteiro16:01:45

@nxqd: parser's read methods would be helpful

jimmy16:01:43

yup that's all

anmonteiro16:01:49

I'd say some things are not quite right in your approach

anmonteiro16:01:59

you eventually have to return some data in your client's reads..

anmonteiro16:01:33

your app state also looks kinda spotty

anmonteiro16:01:10

I'm not sure why you have :dom-com/props in your state, this is supposed to be a bogus key only used for routing. notice that the parser recurses on this key

anmonteiro16:01:31

in short: your :project-page client read method needs to actually grab something from the local state whenever the remote data has been merged

jimmy16:01:54

hmm I think I misunderstand something here. So the {:value in read function does take the data from remote when they are returned as well ? Is it only used for local data ( cache ) only ?

anmonteiro16:01:35

@nxqd: nothing in the parser is automatic

anmonteiro16:01:22

remote instructs Om to grab remote data, that data is merged into your app state whenever you call the callback in your implementation of send

anmonteiro16:01:53

when your parser runs in local mode, and the remote data you just fetched is there, you need to go get it

jimmy16:01:14

so after being instructed to get data from remote. When it gets data from remote it will re run the read again ?

jimmy16:01:40

nice, that clarifies thing.

jimmy16:01:52

@anmonteiro: again, you are correct, now I have the same question why I have data in :com-dom/props ? I should have data in :project/page instead right ?

jimmy16:01:25

I might have the same question as @ztalky ask in the morning. I can see that we have the recursive call in read :dom-com/props. But the thing is even if I return {:remote true} in subquery, it doesn't hit the server. The query only hits the server when I return {:remote true} in root query.

anmonteiro17:01:14

@nxqd: right but that is something we already discussed

jimmy17:01:33

I think I should re read the discussion.

anmonteiro17:01:16

in summary: since you are using recursive parsing, the parser at the top needs to know if the parsers that it calls need to go remote

anmonteiro17:01:50

in your case, you can simply replace {:value (parser env query target)} with (parser env query target

anmonteiro17:01:04

and remove the remote too

anmonteiro17:01:12

let the underlying parser decide what to do

anmonteiro17:01:50

these two functions come to mind as an example of what's being discussed here: https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs#L191-L228

jimmy17:01:03

yes it's exactly what I'm going to try.

jimmy17:01:35

thing becomes clearer now, thanks for helping as always 😄

mrjaba17:01:31

In the context of Om.next - what are "colocated queries"? in the second tutorial it introduces this term, but I'm not quite sure what it means

jannis17:01:21

@mrjaba: Colocated means that queries are defined along-side / as part of the component logic / definition

hugod18:01:35

@geraldodev thanks, but I don’t think that is my problem (I’m not using get-in)

hugod18:01:20

I think my issues are all related to components being created in code paths that are outside of an om controlled render.

anmonteiro19:01:22

@dnolen: regarding our conversation earlier today (about tempids), it looks like it does work as expected, so I must have been doing something wrong yesterday

anmonteiro19:01:01

and there are tests in place for :id-key

dnolen19:01:28

@anmonteiro: still something I’ve been thinking about - how to catch typical broken invariants and emit meaningful errors/warnings when things go wrong

anmonteiro19:01:30

test-tempid-migration uses an id key

dnolen19:01:33

copying React here is not a bad idea

dnolen19:01:40

and an easy way for people to contribute

anmonteiro19:01:13

@dnolen: I like your line of thinking there

dnolen19:01:16

basically anytime someone in this channel says “why doesn’t X work?"

anmonteiro19:01:23

we add an invariant

dnolen19:01:36

it would be nice to check to see if we can warn/error about it

anmonteiro19:01:43

React's mechanism would probably work well

anmonteiro19:01:48

I know they use it a lot

dnolen19:01:02

we can just make these asserts, production-elidable

anmonteiro19:01:35

yep. does cljs's compiler elide those?

anmonteiro19:01:43

when you use elide-asserts

anmonteiro19:01:17

so no additional logic to be implemented, just really use normal assertions

dnolen19:01:58

yes definitely a good first step - maybe later consider a custom warn macro or something that doesn’t hard error

anmonteiro19:01:00

@dnolen: can also make a simple macro that uses goog.log, people will have it on in development

anmonteiro19:01:44

that wouldn't hard error

dnolen19:01:34

yes happy to see something like that added

anmonteiro19:01:55

btw, PR#575 is just scratching the itch that I've had since I've seen query->ast and then ast->query for each function call. It's a minor thing but using query-template & replace seems like a great fit there

dnolen19:01:05

you can still hook into :elide-asserts for those as well

dnolen19:01:14

macros can see the compiler environment

anmonteiro19:01:41

Maybe I'll have some time on the weekend to work on that. I'll file an issue just for reminders

dnolen19:01:40

574 merged

dnolen19:01:44

less code is better

anmonteiro19:01:45

hah! didn't think about that

anmonteiro19:01:56

I agree, thus submitting it simple_smile

anmonteiro19:01:32

@dnolen: btw: when I run the tests at the node.js repl, I have to restart it to make it see the new code updates

anmonteiro19:01:49

and (require 'om.next.tests :reload) or :reload-all doesn't seem to do anything

dnolen19:01:37

@anmonteiro: hrm the later bit seems weird to me

dnolen19:01:58

I usually just use the load-file special fn via my IDE/text-editor key bindings to re-eval the contents

dnolen20:01:23

:reload should work though

dnolen20:01:51

it may not work if you are in the ns itself ...

anmonteiro20:01:05

well, typing (in-ns 'bogus) and then requiring the tests again still sounds better than restarting the whole repl

anmonteiro20:01:20

let me confirm that it works

anmonteiro20:01:35

@dnolen: nope, still doesn't work

anmonteiro20:01:11

it does work in the figwheel repl, though, without switching namespaces

anmonteiro20:01:34

not sure if a bug in the node repl, or if it's a result of figwheel hotloading

dnolen20:01:02

@anmonteiro: that’s just figwheel hotloading

dnolen20:01:10

trying now here

jeremyraines20:01:23

I have a question about semantics; this probably isn’t the perfect place for it but happy to take pointers elsewhere. If Om is characterized as “Graph Query View”, what does the Graph part mean exactly? Similarly for GraphQL. How are the links between objects, or the system’s treatment of them, different in quality from relations in a relational db (or are they not — since the graph is a higher level idea and you can represent a graph in a relational db)

dnolen20:01:11

@anmonteiro: hrm weird yeah I see that - probably some kind of cljs.test bug

dnolen20:01:33

@jeremyraines: except representing graphs in a traditional SQL store is a complete pain

dnolen20:01:40

there’s a reason Graph DBs are thing

anmonteiro20:01:04

gonna start running tests in figwheel

anmonteiro21:01:43

@dnolen: I could probably get your om-next-demo updated with instructions on how to run it, and running, for people to clone it and get it running in their machines

anmonteiro21:01:12

if that's something you'd like

dnolen21:01:19

@anmonteiro: if you feel up for that, feel free to take that on - but don’t feel obliged simple_smile

anmonteiro21:01:42

It's something that people are always asking how to run

anmonteiro21:01:02

but it doesn't seem complete

anmonteiro21:01:22

e.g. UI doesn't update when you delete a todo

anmonteiro21:01:01

looks like a good example of an app with clojure backend & datomic; I'd say it would be good to get it up and running both as a showcase and as an example for people to tinker with

anmonteiro21:01:51

by the looks of it, I'd say there are things that you didn't have time to implement?

dnolen21:01:39

right mostly the finesse bits

dnolen21:01:55

also would like to update the CSS etc. from the latest TodoMVC but lower priority

anmonteiro21:01:53

@dnolen: if there are any other things that you remember are missing please say so, for me to note it down

anmonteiro21:01:13

also forgot to open the invariant issue, going to do that now

dnolen21:01:00

@anmonteiro: that’s not really one issue

dnolen21:01:34

for that I will happily just takes PRs as people encounter good places to introduce assertions

anmonteiro21:01:57

right, but the macro thing is there too

dnolen21:01:06

ah right yeah

dnolen21:01:21

so invariant checking support might be a good title for that issue

anmonteiro21:01:27

and I had literally just clicked the 'Add' button when I read what you just said 😇

tony.kay22:01:00

@dnolen: You had questions?

tony.kay22:01:05

Sorry, busy so my avail is spotty. I'll be around in 30 mins or so, or possibly in the morning

griff23:01:09

Have anybody else experienced that Safari is extremely slow or crashes when using Om Next?

dnolen23:01:52

haven’t heard of anything like that

dnolen23:01:07

@tony.kay: no rush for me, can chat about it tomorrow

griff23:01:26

When I run https://github.com/omcljs/om/wiki/Queries-With-Unions the first button press is VERY slow.

dnolen23:01:55

@griff a right there’s a known bug with older Safari’s if you don’t use optimizations

dnolen23:01:02

nothing to do with Om

dnolen23:01:10

purely a ClojureScript code gen + Safari

dnolen23:01:14

and it’s a Safari bug fundamentally

akiel23:01:16

Is params of IQueryParams considered to be pure or is it ok to have a param like the current location path for routing?

griff23:01:31

@dnolen: OK thanks. But is it just older Safari’s? Because I am pretty sure that I am on the latest.

dnolen23:01:42

no idea when it was or if it was resolved

dnolen23:01:46

radar issue exists

dnolen23:01:26

@akiel: I don’t know what you mean, if you mean sticking an atom in there, no not generally a good idea

dnolen23:01:39

if you mean whether the query should be allowed to change over time - yes that’s the idea

akiel23:01:42

@dnolen: I mean the latter - changing the query over time - but without using set-query!

akiel23:01:21

but than if this is the idea - I miss a clear way to force a re-render of a component with such query params

akiel23:01:21

using set-query! changing the params to a value which would be the same as when params would just be re-evaluated seems strange

dnolen23:01:01

re-rendering when nothing has changed is orthogonal to queries

dnolen23:01:11

there’s an issue for adding a helper for this case