Fork me on GitHub
#om
<
2016-04-28
>
dimiter00:04:46

Stupid beginner question, moving from OM to OM Next, having some trouble grasping how to manage remotes. For mutations (e.g. User Up-Votes something, ) Do I need to use remotes, or can I define a mutation and use my own logic in the mutation to push the change up to the server.

fifigyuri07:04:31

@dimiter: a mutator can list a remote or remotes it’s syncing with, than the :send function defined in reconciler will handle the request. You can do anything you want in a mutator, but remote synchronization and updates are supposed to be done in send, that’s how I've seen it in every tutorial so far. I think it’s a good convention

fifigyuri08:04:49

I’m a bit confused about updating app state from remote. I’ve made a simulated a remote which responds after some delay on a modified code from https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-Normalization. I simply put random values for age and points and called (cb (rewrite ...)). But the view is not updated although the :person/by-name referred by ident changed, the generated values are rendered only after the next transact. This is the changed code:

fifigyuri08:04:24

I certainly have incorrect expectations about app state updates. I’ve seen watches on atoms in the om-next code and thought that changes on keys referred by indent will queue components to re-render. It’s obviously not so. How can I reach that updates coming from a remote will be rendered?

petterik09:04:04

I'm trying to create more dynamic queries with alpha34, so I've got components that change with om/props but the reads sent with my remote mutations are not up to date. Does it makes sense for queries to depend on a component's props? For example: anmonteiro's subquery routing example calls (om/props this) (I use a similar strategy). Then is it a bug that we transform reads in (om/transact! ...) before mutations has occurred in (om/transact* ...)? Shouldn't we want to transform our reads after the parser has executed the mutations, before calling gathering-sends?

jplaza13:04:32

Does anyone has a working example of a more realistic application? With routing remote reads, etc

telent14:04:24

quick question for Om Now: I have a form containing a button and it is doing a form submit when I click the button. What should I do in onClick to stop that (or in onSubmit on the form element?)

telent14:04:34

returning false seems to have no effect

devth14:04:52

given:

{:people/by-id
 {1 {:person/name "Sally", :person/age 33},
  2 {:person/name "Jesse", :person/age 43},
  3 {:person/name "Bo", :person/age 13}}}
how do I query only the :person/name field for all people/by-id? I thought it was simply: [{[:people/by-id _] [:person/name]}] but that returns {:people/by-id {}} and [{[:people/by-id _] [*]}] gets me the entire structure.

devth15:04:14

@telent: (.preventDefault e)

devth15:04:26

in :onSubmit

jplaza15:04:43

Does anyone has a working example of a more realistic application? With routing remote reads, etc

tomjack18:04:14

devth: there is no "query for all people/by-id". [:k _] is meant to refer to a top-level property on the app state, not an entire table

tomjack18:04:58

say e.g. {:app/all-people [[:person/by-id 1] ...]} in your app state, then [{:app/all-people [:person/name]}] makes sense

tomjack18:04:58

er. [{[:app/all-people _] [:person/name]}]

tomjack18:04:44

the _ just means "go back to the top of the app state"

devth19:04:31

tomjack: you're saying db->tree can't do it on its own and I have to implement some custom read?

devth19:04:52

i was just playing with https://awkay.github.io/om-tutorial/#!/om_tutorial.D_Queries/ident-based-queries and trying to figure out how to get all the :person/names.

devth19:04:46

similar to [[:people/by-id _] [*]] but only :person/name instead of all fields.

tomjack19:04:40

Right, there is nothing in the query language designated to mean "everything with this ident key", so db->tree won't really do what you want

manutter5119:04:44

bear in mind that the part of the tutorial you’re looking at is focused specifically on the task of looking things up by ident, so it doesn’t have the full data set you’d normally find in a working UI

tomjack19:04:26

You could do it in your read somehow, or you could adjust your state

manutter5119:04:31

Normally if you wanted a list of names, you’d have a top-level entry somewhere with a vector of the idents of the people you’re interested in.

manutter5119:04:45

then you’d just do a join to get the names

tomjack19:04:44

Yeah, I would consider adjusting the state by just putting all the people under a top-level entry like that

devth19:04:56

i see. seems a little weird that I can just sloppily specify my query to be [[:people/by-id _] [*]] and get what i need (and more).

devth19:04:23

instead of doing it "the right way"

tomjack19:04:31

That's tricking db->tree

devth19:04:23

i think i've been avoiding creating custom read functions. i just want db->tree to give me everything i need. because read functions all end up looking pretty similar.

tomjack19:04:40

It's not going to protest if you access the data in a table as if it wasn't a table

tomjack19:04:25

Maybe I'm confused about what you're seeing, though..

devth19:04:57

i probably need to embrace writing very-similar-looking read fns everywhere. i just don't get it yet.

fifigyuri19:04:16

I’m a bit confused about updating app state from remote. I’ve made a simulated a remote which responds after some delay on a modified code from https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-Normalization. I simply put random values for age and points and called (cb (rewrite ...)). But the view is not updated although the :person/by-name referred by ident changed, the generated values are rendered only after the next transact. This is the changed code:

fifigyuri19:04:42

I don’t understand why the component is not changed, or queued for rerender after the :persons/by-id entries were changed. I’ve seen watches on atoms in the om-next code and thought that changes on keys referred by indent will queue components to re-render. It’s obviously not so. How can I reach that updates coming from a remote will be rendered?

hlolli19:04:57

@fifigyuri: The factory on the person ui, you map person to the symbol 'list' that should contain :name, but are you passing :name from root to ListView, or try querying :name from Root? Just throwing ideas.

hlolli20:04:21

ps. watch out for using clojure.core variable names for local variables, maybe you are aware of course.

fifigyuri20:04:33

@hlolli: the confusing part for me is that this code just adds the :remote to the mutator. The original tutorial example is increasing the value, here I simply make an update after some delay. The re-rendering happens only after the next transact!, so the app-state is updated but the component re-rendering does not follow

fifigyuri20:04:36

thanks for the idea, but the original code has it the same way :name is queued from the Person there too

hlolli20:04:06

Haven't done this tutorial, I've had there rerendering problems all too often. Usually something with IQuery that was forgotten or overestimated. Try printing (om/props this) from Root down to persons, to be sure that you are getting the values passed trough and they are being queried.

fifigyuri20:04:20

They get through, as I mentioned they get re-rendered on the next transact! so the queries are fine, but I do not understand what triggers queuing the component to re-render. btw. that tutorial revealed me the concept of idents, good tutorial, just hit this problem 😞

hlolli20:04:14

nice then I need to check it out.

isak22:04:57

for remote mutations with idents (and it is not a tempid) - should the server treat that as an upsert or an update?

tomjack23:04:54

since you're doing (transact! this ...) in a Person, with no reads given in your tx, only that Person will rerender

tomjack23:04:33

er, nevermind, that is not your problem

tomjack23:04:46

or not the usual version of that problem. but related. there needs to be something in the query you pass back to cb which causes the rerender

tomjack23:04:13

you don't pass a query back; seems like you should. (cb ... remote) there, I guess?

tomjack23:04:39

I'm not sure if it makes sense to pass data back in the shape you have

tomjack23:04:58

if you customize :merge for your reconciler, maybe

tomjack23:04:10

for the default merge, you are supposed to pass a tree back, not normalized data

tomjack23:04:32

it seems kind of weird to do that, though

tomjack23:04:14

I'd look for :send in next.cljs to find the relevant spots. in the case you're hitting (through send! in Reconciler, I think?) only the keys of the delta determine what gets queued

tomjack23:04:59

so my snippet has a tree with the idents as keys, with an ad-hoc query which matches that tree

tomjack23:04:46

normally you would do something like, maybe, (cb {:list/one [...] :list/two [...]} remote) and add :list/one :list/two to your txs

tomjack23:04:11

(and make sure they make it through to send..)