Fork me on GitHub
#om
<
2015-12-24
>
maackle00:12:37

yep. I used add-root! and it’s re-rendering fine now. So it was devcards.

roman01la02:12:18

With queries in Om Next, is it possible to get a query if for some reason there are a pure component between two components with queries?

dnolen02:12:58

@roman01la: yes that should work

dnolen02:12:16

all components have parent pointers that are used to crawl the hierarchy

dnolen02:12:25

some caveats here for random JS React components you might integrate, but I don’t think a real problem for the most part since I don’t see much value in these existing anywhere but at the leaves

roman01la02:12:02

@dnolen: I don’t know if there exists any reasonably big apps built with Om Next, but what’s the practice of using components with queries in Om? For example in JS world it’s common that you don’t want much of these “data aware” components on a single view.

dnolen02:12:51

@roman01la: I do not know what you asking

dnolen02:12:11

either you misunderstand the goal or you are phrasing your question strangely (for me anyway)

dnolen02:12:18

as to the JS world - there is no real innovation in the JS world wrt. UIs

dnolen02:12:32

it’s the same techniques long in practice in traditional OOP-y UI work

dnolen02:12:13

(React is a rendering thing which why you have a crazy number of approaches - nobody sorted it out at all that well yet)

roman01la02:12:11

@dnolen: Sorry. I mean, usually when I’m doing a project with React in JS, I have as less as possible components which are somehow connected to application state. I'm trying to understand if it's the same with Om. Should I have only a few components with queries and pass data down the tree using props?

roman01la02:12:56

Or should I use queries extensively across the whole app.

dnolen02:12:00

@roman01la: you can do whatever you want

dnolen02:12:04

pure components are still useful

dnolen02:12:11

if a component doesn’t need queries don’t use queries

dnolen02:12:09

@roman01la: the point of queries is directly tied to the fact that data comes from “somewhere else"

dnolen02:12:40

and that you want components to specify what they need yet achieve total coordination of UI state synchronization

dnolen02:12:25

everytime you hear somebody struggle with React and synchronization, caching hacks, uncoordinated fetches, async props

dnolen02:12:29

all this stuff

dnolen02:12:35

you should think - that’s a mess

dnolen02:12:49

and Om Next just gets rid of that via queries

roman01la02:12:04

@dnolen: Now I understand, thanks. One more question: I’m trying to figure out how to validate queries on the server. It sounds cool that client can ask for data it needs, without adjusting code on server. But what if there’s auth, some permissions for data access. Wouldn't this still require you to go and change something on server?

dnolen02:12:01

Om Next is actually 100% agnostic about the backend

roman01la02:12:07

I feel like I still need to write some validation logic for every type of request.

dnolen02:12:16

it just passes along a query and it’s up to the server to deal with it

dnolen02:12:31

traditional approaches apply - the only difference is that it not a single requests

dnolen02:12:35

but a fan out of requests

dnolen02:12:20

@roman01la: yes Om Next doesn’t try to magically solve the validation problem, that’s code you would have to have written anyway

dnolen02:12:34

you can in fact think of queries as getting a bunch of REST requests all at once

dnolen02:12:28

so it’s no easier or harder than it was before wrt. to validation / authentication

dnolen02:12:21

the benefits are simplification for clients and simplification for backend to be able to service many clients without even more bloating than you already have

dnolen02:12:05

this rationale btw is well covered by Relay & Falcor

dnolen02:12:14

Om Next provides little in the way of novelty here

roman01la02:12:45

Thanks. Now I need to think about it.

peeja03:12:01

I'm a bit confused as to what keys I need to provide a defmethod read for. Is it only the top-level keys of the root component's query? I've been assuming that read was meant to be recursive, but I haven't seen any examples of that.

peeja03:12:51

That is, if I have posts and comments, should (defmethod read :posts …) be returning the comments as well?

peeja03:12:45

If I query for [{:posts [:body {:comments [:body]}]}], should that end up reading from a (defmethod read :comments …) or just (defmethod read :posts …)?

dnolen03:12:32

@peeja: read can be recursive but it’s not strictly necessary

dnolen03:12:38

it depends on how much you can leverage db->tree

dnolen03:12:03

in the big picture read is not even necessary

dnolen03:12:10

parse is a completely abstract thing

dnolen03:12:27

you can implement it however you want

dnolen03:12:54

the current read mutate split is provided just as a stepping stone / default

dnolen03:12:55

@peeja: gotta run but you should look at what people like @jannis and @tony.kay are doing for examples of using db->tree to take care of this. That or look at the devcards in Om itself.

peeja03:12:33

Ah, okay, that makes sense.

peeja03:12:11

I get the feeling that there are a lot of things in Om Next that make it easy/possible for lots of different things to work, but I've been assuming I'm supposed to be using all of them. simple_smile

steveb8n06:12:30

can anyone help me understand why the parser changes the type of tempids when performing reads on the jvm? Check out the snippet below...

steveb8n06:12:37

because of this I can’t use tempids from query results to lookup values from :om.next/tables in my jvm code

steveb8n06:12:21

in case you are wondering why I’m doing in clj and not cljs, I’m testing the dev workflow of using cljc to build an om.next app and only using cljs for the app and components

dnolen15:12:42

@steveb8n: that’s the same issue reported by @r0man, records don’t get preserved currently

peeja16:12:54

If you have two components that render the same data—say, a PersonOverview that shows up in a list of people, and a PersonDetails that renders a larger view—how do you choose which to put the Ident definition on? Do you need it on both?

dnolen16:12:49

@peeja: you can use idents more than once

dnolen16:12:55

simplest way to keep things in sync

peeja16:12:48

Doesn't that mean duplicating code? My instinct is that that would be a potential problem.

dnolen16:12:03

duplicating what code?

peeja16:12:12

Duplicating the Ident definition

dnolen16:12:23

this is not a problem

dnolen16:12:34

yes you will have to write 2 lines of code

peeja16:12:06

Right, I'm not worried about writing an extra 2 lines, I'm worried about it changing in one place and not the other. But maybe it's just simple enough that it doesn't matter?

dnolen16:12:52

so write a shared function to compute ident and call that instead

dnolen16:12:00

then you can change it one place

peeja16:12:18

Yeah, fair enough. That makes sense.

peeja16:12:57

Ah, right, so reusing that function is how you actually say "These components use the same thing"

peeja16:12:17

Awesome, thanks!

jannis20:12:38

I know we're celebrating it early in Germany but: Merry Christmas everyone! It's been a pleasure joining this awesome community and I hope you all enjoy a peaceful time with friends and families. simple_smile

mudphone21:12:33

I have hopefully a simple question. I have a top level component that pulls a key for a query, and then doesn’t re-render when I update that key in the app state. But, this only happens the first time I update the state. After the first update, the component re-renders. Is there some other part of the mutation that I need to check? I tried looking at returning :value from the transact! call, but that looks like it’s for dev convenience.

sander21:12:04

@mudphone: what does your transact! call look like?

mudphone21:12:57

`
(om/transact! this `[(page/select {:page ~page})])

(defmethod mutate 'page/select
  [{:keys [state]} key {:keys [page]}]
  {:value {:keys [:sentence/tucked :page/current]}
   :action (fn []
             (swap! state
               #(-> %
                  (assoc-in [:sentence/tucked] true)
                  (assoc-in [:page/current] page))))})
`

mudphone21:12:38

@sander: I’ve tried it a few ways… it turns out, it’s any component at the top level, tied to a key on the app state, when changed for the first time.

mudphone21:12:41

For example, if I just toggle :sentence/tucked it’s supposed to toggle a CSS class… but, it only runs render on that component after hitting it the second time.

sander21:12:41

@mudphone: there's no read in your transact call so nothing will be read

sander21:12:35

probably needs to look something like this:

(om/transact! this `[(page/select {:page ~page}) sentence/tucked page/current])

mudphone21:12:42

@sander: well that works… how did I totally miss this concept?

mudphone21:12:57

so, I need to read out the values that I’m updating in the state?

mudphone21:12:18

or that are relevant to updating my chosen components

sander21:12:29

@mudphone: you need to tell om to read out the values that you want to be read out after the mutation simple_smile

mudphone21:12:51

even if I don’t use them, just to be read out after mutation for the sake of updating the UI?

mudphone21:12:59

(just to clarify)

sander21:12:30

i have little experience with om.next, but that's how i think about it yes

sander21:12:50

'updating the ui' counts as 'using them' in my view

rhansen21:12:13

@sander, @mudphone: I think you can avoid this if your mutate fn returns {:value {:keys [:some/key]}}

mudphone21:12:26

for some reason, I thought that was what the [:value :keys] vector on mutate was for.

mudphone21:12:35

@rhansen: I tried that, and it didn’t seem to work for me

sander21:12:47

i think the docs or the source docs say that :value is really just a hint that you as a dev can use

mudphone21:12:03

@sander: it does, I was just desperate simple_smile

mudphone21:12:26

thank for the help

mudphone21:12:40

I think the answer for me tends to be, maybe I should have read the source simple_smile

mudphone21:12:56

that’s 2 of 2 questions here so far

mudphone21:12:05

there’s a lunch with my name on in the next room… thanks for helping me out on your holiday!

sander21:12:23

glad to help simple_smile enjoy your lunch

mudphone22:12:22

@sander, @rhansen: one note, I didn’t have to worry about this until I switched to having Om normalize my state for me… i.e. it’s not required if you pass the reconciler an atom.