Fork me on GitHub
#om
<
2016-09-14
>
levitanong10:09:03

Just trying to formalize my knowledge of om.next: Is it true that all reads are performed only against queries of the top level component, and that the queries of subcomponents only serve to help the top level component build a “master query”? If the above is true, then does it also mean that all query params must reside in top level components?

anmonteiro10:09:47

@levitanong you could say that for most cases

anmonteiro10:09:09

but what really shines about Om Next is that the query of each subcomponent is also valid by itself

levitanong10:09:03

But that would only be relevant for repl-based testing, yeah?

anmonteiro10:09:26

also for incremental rendering, for example

anmonteiro10:09:34

where you can start computing queries at an arbitrary subtree

anmonteiro10:09:41

or for recursive parsing, where you call the parser on a subquery

levitanong10:09:16

Is there any reading material for that? 😁

levitanong10:09:23

I’d like to find out more

anmonteiro10:09:54

@levitanong I don’t think there is

anmonteiro10:09:00

there are a few code samples here and there

anmonteiro10:09:02

let me try and find some

levitanong10:09:29

Also, I ask my original question because I’ve been working on a problem, you see: I have a :current-something-id I’d like many components to have access to. This is an indication that the value should be in app-state so the components can query it. However, :current-something-id is also needed information for a remote. i.e. When :current-something-id is selected, additional information about it should be pulled from the server, so that should be part of my ajax request. The problem with this is, the send fn that is passed to the reconciler doesn’t have access to state. Only params. If I make :current-something-id a query-param, then the other components that want to know its value have to go through a more indirect route. This is the path I’m currently taking, and it feels a little ugly. Do you have any suggestions?

anmonteiro10:09:20

@levitanong it looks like the AST would be the way to help you there

anmonteiro10:09:41

in your parser function you have access to the state, so you can modify the AST that gets sent to the server

anmonteiro10:09:20

e.g. instead of returning :remote true, return :remote the-modified-ast

levitanong10:09:24

but where would the modified ast show up?

anmonteiro10:09:25

for recursive parsing, this should have some examples: https://github.com/awkay/om-tutorial

levitanong10:09:35

in my experience, I’ve found that when I get the remotes from the send-fn, they’re in the form of queries, and not ASTs, which is why one calls (om/query->ast query)

levitanong10:09:09

unless the modified ASTs somehow get turned into queries?

anmonteiro10:09:14

@levitanong that’s right, but if you return a modified AST in the parser, Om will convert that to a query

levitanong10:09:15

when the parser sends to send-fn?

anmonteiro10:09:26

^ what you said 🙂

levitanong10:09:30

okay, it’s all coming together now!

levitanong10:09:08

I’ve always felt a little uneasy about using query params because I like keeping as much of state in application state as possible

levitanong10:09:14

but could never do so because of the remotes thing

levitanong10:09:45

Thanks, @anmonteiro! You are a gift to the clojure/script community 😄

anmonteiro10:09:16

np, and I wouldn’t go that far 🙂

anmonteiro10:09:42

@levitanong anyways your questions gave me an idea for a blog post

anmonteiro10:09:54

I’ll write up something on path optimization soon

levitanong10:09:56

Well, you do work on clojurescript. 😛 big thing in my book

levitanong10:09:44

Looking forward to reading your post! Will also read the devcards!

anmonteiro11:09:18

if anyone wonders why om.core and om.next live in the same repo ^

anmonteiro11:09:26

also if you want to help keeping the Wiki up-to-date!

jfntn13:09:32

I have a send fn that's passing a result like {'sym {:result {:tempids {#om/id["-1"] 123}}}} to the callback, but default-migrate is getting {} as its tempidsargument

jfntn13:09:59

What result shape does the reconciler expect for remote tempids substitution?

anmonteiro13:09:04

@jfntn I think you need to pull :tempids out of the result

anmonteiro13:09:47

such that it becomes e.g. {'sym {:result {} :tempids {#om/id["-1"] 123}}}

jfntn13:09:11

@anmonteiro ok cool, now default-migrate is getting {[:db/id <#C06DT2YSY|om>/id["-1"]] [:db/id 123]} but the default-merge gives me something unexpected, replacing the app state with the result...

anmonteiro13:09:59

@jfntn your app state is normalized right?

jfntn13:09:03

@anmonteiro ah indeed my optimistic update was assoc’ing into the denormalized path, I changed it to {:denorm [:db/id <#C06DT2YSY|om>/id["-1"]] :db/id {#om/id["-1"] ...denorm-data…} but I’m still getting nothing but the remote result in the app-state after it's migrated

peeja14:09:41

@anmonteiro I think I've misunderstood how idents work in Compassus routes. I assumed that that [:item/by-id 0] and [:item/by-id 1] would use the same route, but I understand now that {[:item/by-id 0] Item} literally means that when the route is that ident, the selected component should be Item. What would you use that for? Wouldn't it be more useful to have a route that applied to all idents of a particular "type"? I can't list every Item that's in the database in my routes map.

anmonteiro14:09:18

@peeja yep, that was definitely your misunderstanding 🙂

anmonteiro14:09:36

for now you cant’ do that programmatically

peeja14:09:28

What's the intended use case for it?

anmonteiro14:09:06

@peeja at the moment just static things as you can see

peeja14:09:41

I may be just missing something about how Om Next is meant to work, but why would you have idents for static things?

peeja14:09:48

(non-singleton idents)

anmonteiro14:09:14

@peeja hrm. I think the answer that most applies is “why wouldn’t you?"

anmonteiro14:09:27

probably not the most common case, but still 😛

peeja14:09:36

Aren't things with ids typically dynamic?

anmonteiro14:09:18

yeah, probably not a very common use case, as I said

anmonteiro14:09:48

still for the bounded case might be useful [:tab/type :related], etc.

peeja14:09:16

Ah, I see.

petterik16:09:19

FYI: Updating om from alpha37 to alpha44, I'm getting core.cljs:5428 Uncaught Error: Index out of bounds in cljs.core/subvec used from https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1832 After doing some printing, I found that (let [update-path (path c)] on line 1829, return update-path as nil. I suspect this is because my c does not implement om/IQuery.

anmonteiro17:09:05

@petterik that might need a little tweaking, thanks for reporting

anmonteiro17:09:55

did you succeed at producing a minimal case? it isn’t obvious to me how a component that doesn’t implement IQuery would end up in reconcile!

petterik17:09:14

My component c was updating it's own state, maybe that's how?

petterik17:09:16

I worked around the issue by giving the props I pass to c :om-path in its meta

petterik17:09:26

I'll see if I can create a minimal case

anmonteiro17:09:33

yep, that’s one way it would end up there 🙂

anmonteiro17:09:39

there’s probably no test for that

anmonteiro17:09:35

@petterik probably worth opening an issue and I’ll get to it today

petterik17:09:48

Ok, I'll write one

petterik17:09:04

@anmonteiro not sure I'll get to creating a minimal case today. Working on updating a bunch of dependencies. Do you think you need one?

anmonteiro17:09:36

@petterik nope, your set-state! suggestion will probably work for reproducing that

anmonteiro17:09:28

@petterik hrm actually I don’t know about that

anmonteiro17:09:59

that means we only go into that for props changes

petterik17:09:14

@anmonteiro that is weird. I'm currently passing {} as props

anmonteiro17:09:28

hah. I might know what’s wrong

anmonteiro17:09:04

that probably results in (om.next/t {}) being a weird value

anmonteiro17:09:39

@petterik is {} the root props?

petterik17:09:17

@anmonteiro Not sure what you mean? The root component's props are not {} and the component c's parent is not the root component

anmonteiro17:09:47

because what I said about t might not apply

petterik17:09:18

So hang on a minute. I think I'm seeing this error only after a merge? Would that make sense?

anmonteiro17:09:13

could be, repro would be ideal

petterik17:09:20

Yeah, let me do that

ethangracer18:09:50

pull syntax taking over the world, one tech conglomerate at a time

ethangracer18:09:42

interesting timing?

anmonteiro18:09:10

definitely arranged

dnolen20:09:59

@anmonteiro need to rebase the server side rendering commit

anmonteiro20:09:23

@dnolen gotcha, doing it now

anmonteiro20:09:13

@dnolen rebased, want me to squash the 2 commits?

dnolen20:09:50

much excite!

anmonteiro20:09:02

note that now there are Clojure and ClojureScript tests

dnolen20:09:07

yes I saw that

anmonteiro20:09:10

you can run them with boot test

anmonteiro20:09:13

it’ll run both

anmonteiro20:09:27

not sure how you’ll be doing that with your preferred build tool

anmonteiro20:09:36

I can probably make it work with Lein too

anmonteiro20:09:04

@dnolen wondering at this point we should maybe set up CircleCI for running tests in PRs and stuff?

dnolen20:09:33

that would be cool, I don’t have time to work on that myself but I would be happy to see it done

anmonteiro20:09:47

@dnolen happy to do it, but would need access to the org

anmonteiro20:09:23

@dnolen going to be pushing 1 or 2 commits with the circle config then

anmonteiro22:09:35

@dnolen any chance you could release one more alpha to give the latest stuff a go?

jasonjckn23:09:14

is omcljs$parent any different between simple optimized builds and none optimized builds

jasonjckn23:09:41

because that's what i'm observing right now

anmonteiro23:09:06

@jasonjckn might be due to Closure Compiler munging

jasonjckn23:09:03

@anmonteiro i'm only using simple mode

jasonjckn23:09:05

I copied over some of om.next internal code into my own project, but I thought closure compiler would be fine with this

jasonjckn23:09:16

(defn parent
  "Returns the parent Om component."
  [component]
  (get-prop component "omcljs$parent"))

jasonjckn23:09:20

i copied that into my project

anmonteiro23:09:25

Simple optimizations also perform munging

anmonteiro23:09:33

and that should be OK