Clojurians
#om
<
2015-10-28
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

jannis00:10:49

Yay. Added creating cards, deleting cards via DND, toggling card assignees by clicking on them in the card dialog to the kanban demo. It's all too easy. :simple_smile:

drcode00:10:41

Hi, I have a minimal example that generates an error that I don't understand: https://gist.github.com/drcode/0b4a2917b02b2c54c55b

drcode00:10:40

This example has a parent and child component. If you press the button the parser complains about a missing read function

drcode00:10:02

The problem is it wants a read function for a query tag that's deeply inside the absolute query, at which point it seems impossible for me to give a meaningful read function, since all context is missing

drcode00:10:11

My impression was, read functions for the parser are by default only at the top level, unless you write a recursive parser. Therefore, this error seems to make no sense.

drcode00:10:12

My questions: (1) Is this error expected behavior, or is this a bug in om next? (2) If it's not a bug, why is the parser parsing something ONLY when I call "set-state!"?

drcode00:10:10

(The other possibility of course is that I'm still misunderstanding query functions and that is causing this error somehow indirectly)

drcode00:10:00

(BTW: This is taken from a larger program that has a richer state structure and more meaningful read functions- I removed them from this minimal example, this is likely not the cause of the error)

thosmos00:10:23

I have a simple modified datascript om.next-tutorial here: https://github.com/thos37/om-tutorial/blob/master/src/om_tutorial/core.cljs#L48-L66 The Counter component has a query that returns an entity that is then wrapped in an atom, watched, and then handed to a reforms form that binds to the attributes of the entity. When the form updates the atom, the watch function does the om/transact!. Does this seem like a reasonable way to do this? It seems like this is a potential use case for a simple om.next/cursor-like-thing to wrap the 'path and transact function into something simpler that can be handed to the forms. Or would that be over-complicating it?

snickell05:10:09

Are there any OM-like javascript clones you guys would suggest? I know, heresay, but alas not free to use clojurescript for this project

locks05:10:49

React :stuck_out_tongue_winking_eye:

snickell05:10:09

oh the irony :wink:

locks05:10:24

I think there was a React+immutable.js+redux setup somewhere or something

locks05:10:29

which you could say stick closer to Om

snickell05:10:46

But in particular, I'm thinking well thought out cursor based central-atom style stores, as opposed to verbose flux style 'write a mutator for every change'

dvcrn05:10:43

@snickell: guess you won't like it then that om.next completely gets rid of cursors and implements mutators for everything :wink:

snickell05:10:24

dvcrn: as long as its not a string matching abomination like flux........

dvcrn05:10:41

what do you mean by 'string matching'?

snickell05:10:05

dvcrn: What I've seen of the reconciler approach of om.next seems a lot more DRY than the various flux libraries I've noticed

snickell05:10:14

dvcrn: Just in terms of: "how many times does the name of this action get repeated" they seem rather verbose

dvcrn07:10:22

hmm I'm still fighting with normalisation. I have the following :send code (stolen from davids om-next demo):

(defn transit-post [url]
  (fn [edn cb]
    (.send XhrIo url
           (fn [e]
             (this-as this
                      (let [val (t/read (t/reader :json) (.getResponseText this))]
                        (cb val))))
           "POST" (t/write (t/writer :json) edn)
           #js {"Content-Type" "application/transit+json"})))
Person looks like this:
(defui Person
  static om/Ident
  (ident [this {:keys [name]}]
         [:person/by-name name])
  static om/IQuery
  (query [this]
         '[:name]))
but the resulting app-state is always empty after normalisation. :normalize is set to true. archive link to my previous post: https://clojurians.slack.com/archives/om/p1445939448003417

dvcrn07:10:03

could the issue be that (t/read (t/reader :json) (.getResponseText this)) returns a map with the keys being string? can that conflict with the normalisation?

dvcrn08:10:24

seems like that was the problem. Changed my (python) server to return this instead (based on https://github.com/cognitect/transit-cljs/wiki/Getting-Started#reading):

test_data = {
        "~:app/people": [
            {"~:name": "David", "~:age": 22},
            {"~:name": "Fred", "~:age": 29},
            {"~:name": "Paul", "~:age": 20},
            {"~:name": "Jiyoon", "~:age": 22},
            {"~:name": "Bob", "~:age": 23},
            {"~:name": "Mark", "~:age": 28},
            {"~:name": "Jiwon", "~:age": 24},
            {"~:name": "Dude", "~:age": 28},
        ],
    }
now the app-state looks like this:
{:app/people [[:person/by-name "David"] [:person/by-name "Fred"] [:person/by-name "Paul"] [:person/by-name "Jiyoon"] [:person/by-name "Bob"] [:person/by-name "Mark"] [:person/by-name "Jiwon"] [:person/by-name "Dude"]], :person/by-name {"David" {:name "David"}, "Fred" {:name "Fred"}, "Paul" {:name "Paul"}, "Jiyoon" {:name "Jiyoon"}, "Bob" {:name "Bob"}, "Mark" {:name "Mark"}, "Jiwon" {:name "Jiwon"}, "Dude" {:name "Dude"}}}

dvcrn08:10:58

should I contribute a wiki page how to use om with a remote server or is that better as a blog post?

hmadelaine10:10:05

@jannis Congratulation for your demo app ! Thank you for sharing

dot_treo12:10:37

@dvcrn that's certainly a gotcha that more people will have a problem with, so I think a blog post should be useful until the documentation in the wiki has an om next FAQ / troubleshooting part

dnolen12:10:22

@drcode: what is the error? You haven't included that anywhere

hmadelaine13:10:51

Hi @dnolen: in order to better grasp the big picture of Om-Next , I am studying Relay and Falcor. Do you have specific suggestion or reading the docs of the official sites will do ? Thanks !

dnolen13:10:21

Just the docs. Also GraphQL spec

hmadelaine13:10:54

Ok thanks :simple_smile:

dnolen13:10:23

Also talk videos are great way to get high level picture

hmadelaine13:10:11

That's what I am watching right now

hmadelaine13:10:54

@dnolen: I am watching lana Kuenzel JSConf 2015. Do you have plan to provide optimistic mutation mechanism in the future ?

dnolen13:10:49

Already exists and way simpler

drcode14:10:57

@dnolen: The error is "Uncaught Error: No method in multimethod 'example.core/read' for dispatch value: :bar"

drcode14:10:19

So now I'm trying to understand why it is calling the parser against the inside :bar tag as opposed to the outside :foo tag (as it does during regular loading of the app)

drcode14:10:19

(and whether calling the parser against the internal :bar tag is intentional behavior)

tord14:10:50

Is there any reason why

om.next/Ident
doesn't follow the naming scheme of other Om/Om Next protocols?

tord14:10:53

I would have expected om.next/IIdent.

dnolen14:10:21

II looks annoying?

dnolen14:10:51

@dvcrn: any reason you’re not using transit-python? or are you?

tord14:10:58

Well, there is om.core/IInitState...

dnolen14:10:10

that’s not om.next

dnolen14:10:24

starting fresh is always fun

tord14:10:34

True enough. Very unimportant, of course, it just seemed weird to me.

dnolen14:10:11

@drcode: looking at your issue, I don’t see anything obvious - trying your minimal example now

dnolen15:10:16

@drcode looks like an Om bug, but also highlights something weird about your example.

dnolen15:10:28

the child gets nil props

dnolen15:10:57

obviously breaking the contract established by the query

drcode15:10:15

Yes, that may have happened when I widdled down a minimal example- Is that issue triggering the bug or are the two unrelated?

dnolen15:10:00

they are related

dnolen15:10:14

but still there is an Om bug here and will have to think about it

dnolen15:10:02

it doesn’t really have anything do with the parsing

dnolen15:10:11

the error you saw is just a red herring to a deeper problem

drcode15:10:45

Yeah, I know there's several different parts involved and I couldn't tease the intended behavior out of it- Thanks for the info, I will work around it with this new information!

dnolen15:10:08

yeah part of the solution may just be disallowing nil props

dnolen15:10:15

that’s really what triggers the bug

dnolen15:10:53

it just doesn’t make sense to allow nils to flow around like this

drcode15:10:00

@dnolen: FYI, when I try to correct the nil props I still seem to get the same error (Not expecting response on this comment, just an FYI for your troubleshooting)

dnolen15:10:06

Basically sounds impossible

dnolen15:10:27

Otherwise local state wouldn't work for anyone. But will check.

akiva16:10:05

I’ve encountered a browser-specific issue. Going through the Queries with Unions tutorial and the code in Putting It All Together is having intermittent issues where it beachballs with Safari 9.0.1 in 10.11.1. Chrome doesn’t seem to have an issue. I’m trying to see if I can figure out how to replicate it reliably but it’s definitely happening.

akiva16:10:03

Yeah. I just restarted Figwheel, reloaded the page in Safari, clicked any ‘Favorite!’ button, and it hangs for five seconds or so. After that, you can click freely except sometimes it’ll hang again.

akiva16:10:37

Not likely an Om problem but I wanted to point it out.

dnolen16:10:26

Doesn't seem Om related at all and haven't seen that.

akiva16:10:01

Yeah, it seems very localized.

dnolen17:10:23

@drcode: k I can repro I think I found your bug

dnolen17:10:30

another case that uncovers multiple issues :simple_smile:

drcode17:10:36

Awesome- At least I'm helping make the product better :simple_smile:

thosmos17:10:15

@snickell: http://omniscientjs.github.io/ sounds like what you're looking for. It's a javascript project based on Om, immutable data, and cursors.

dnolen17:10:42

@drcode also sorted out where to put an error so that you don’t run into these useless misleading errors

dnolen17:10:51

will probably go this route over preventing nil explicitly

dnolen17:10:08

just released 1.0.0-alpha12

dnolen17:10:12

@drcode: ^

tony.kay17:10:21

So, om-next can re-render leaf nodes (and can run a localized query if there is an Ident). I have an example where this leaf node wants to transact on the local state, but also has been passed callbacks. The local transact (on just the localized query state) causes the leaf to re-render (with an isolated query based on Ident), but now the callbacks are not available because the path from root wasn't the source of the re-render.

tony.kay17:10:16

is this related to your example @drcode ?

drcode17:10:39

Not seeing any different behavior on alpha12 I'm afraid, no different error message... both with the version with nil props and there version where I tried to fix by giving proper props.

drcode18:10:29

@tony.kay: Yeah, I'm guessing my confusion is around how om.next handles localized queries (even though I don't have an Ident) but I don't understand my confusion well enough at the moment to speculate more.

drcode18:10:44

@tony.kay: Your example sounds like a great find though, exactly the kind of issue that will trip people up in the future

tony.kay18:10:59

Well, David has said your example demonstrates a bug...but it was unclear to me what the bug is (passing nil as props?). What I ran into seems like a case where the approach needs some touching up, and might be related to the same thing.

tony.kay18:10:31

Seems like for callbacks to be a "reasonable" approach, you need to render (at least) part of the path to that component...as far as I can see, it seems you need to render the path to the child (from root) to ensure that callbacks make it through.

drcode18:10:02

@tony.kay: I agree with what you say about "path to component"

tony.kay18:10:11

I can, of course, "fix it" by including query keywords (to root) in my leaf component transact: (transact! '[(mutation) :parent-state-kw])

tony.kay18:10:16

but the point is that specific mutation only modifies the "leaf"...so having to mention my parents breaks composition/isolation/local reasoning.

tord18:10:19

@tony.kay: Your Om Next overview is very helpful. Thanks for writing it!

drcode18:10:34

@tony.kay: agreed!

tony.kay18:10:12

You're welcome...it is needing some corrections based on these latest realizations (I thought queries always came from root, but they don't)...but it also seems there is a bug related to that...so waiting for a resolution

tony.kay18:10:01

The presence of Ident, in particular, makes it trivial to let Om re-render all of the components with the same Ident, and since Ident is supposed to be client-unique, it is trivial to supply a read that can find the state for the thing with Ident by running a new (isolated query). Unfortunately, this seems to break callbacks.

drcode18:10:06

@tony.kay: Yeah the "queries not from root" thing is something I need to understand better

tony.kay18:10:47

My docs are written (as I clearly state) with an incomplete picture of the inside of David's head :simple_smile:

tord18:10:30

Yeah, the inside of David's head is far too big for a single picture.

drcode18:10:22

I remember when I was first learning CSS, my productivity over time was like 0%, 0%, 0%, 0%, 5%, 20%, %100, %100, %100... so basically a sigmoid curve with a very steep inflection point. Same thing with "om classic"... After I got the hang of it it was easy to be very productive

drcode18:10:06

Now I'm still stuck in the "0% productivity" well for Om Next, but I can see the inflection point in the distance, can't wait until I finally reach it :simple_smile:

tord18:10:14

I'm also stuck close to 0% for Om Next, but fortunately there is no hurry, as I'm already pretty productive with Reagent. I'll stick to that until I reach the Om Next inflection point.

dnolen18:10:24

@drcode: if you're not seeing a new error than you probably have something wrong with your build

drcode18:10:42

thanks, will check on my build

dnolen18:10:34

@drcode: make a new failing example for me to look at once you've verified that's not the issue.

dnolen18:10:54

Note there may be a error reporting bug here. You cannot pass nil props.

thosmos18:10:06

@tony.kay: you mentioned not wanting to add a parent key to your leaf's transact!, but I think you're referring to the query parent. As you said, the render tree needs to exist to that leaf for its callbacks to work. So I think I'm hearing you almost saying that there could be a way to traverse the up the render tree from the leaf in order to make the query tree work?

dnolen18:10:27

@tony.kay: mentioning parent key is wrong. Means you must lift the transaction.

dnolen18:10:35

Callbacks + Ident action at a distance is interesting issue

dnolen18:10:06

Probably need to be a bit more careful here and merge

thosmos18:10:07

@tony.kay: this highlights something I've been wondering about, but haven't done enough experimenting yet to answer for myself, so I'll wonder aloud for now: Could there be a way, by following the render tree path back from any leaf query to a parent query, to be able to assemble a root query automatically (without needing to explicitly describe child queries in the parent query)?

drcode18:10:30

@dnolen: Sorry, was a build issue. Needed to force a clean js build. Everything now appears to be working 100% on my end with Alpha12

dnolen18:10:48

@drcode: cool

dnolen18:10:18

@thosmos: not going to do that

dnolen18:10:26

Too many perf issues

thosmos18:10:08

yeah, plus if there's no direct query dependency between parent and child, then for all intents and purposes they're not really parent/child in the query sense, only in the render sense

dnolen18:10:28

Also path optimization is looming

drcode18:10:50

@thosmos: The way the Om Next approach (potentially) decouples the query hierarchy from the dom rendering hierarchy is really interesting to me.

dnolen18:10:11

And no @tony.kay your issue is not related to @drcode's at all

thosmos18:10:53

@dnolen: path optimization?

dnolen18:10:55

Once people want to do recursive queries re-running query is a disaster

dnolen18:10:17

You need to be able to skip everything and re-render only the child

dnolen18:10:59

@tony.kay: fixing your bug is easy

dnolen18:10:03

The problem everyone is having is "is this a bug or how ya supposed to work" :)

dnolen18:10:10

Keep asking!

thosmos18:10:27

and reverse traversing the render tree from leaf to root in that situation to re-run the root query with only the changed bits is _? It seems like knowing (or being able to decipher) the render tree path from any om.next/Ident component could be useful for the indexer to know how to run just the changed leaf's query all by itself and to know to only trigger a render on it. But again just I'm wondering aloud at this point as I haven't done the research yet.

dnolen18:10:26

What you're suggesting can't be made to work in any simple way I've been able to see.

dnolen18:10:42

The complication is computed local information

dnolen19:10:38

So you cannot just run a components query without throwing that way ...

dnolen19:10:31

But I may have got an idea just now ...

dnolen19:10:57

This problem is related to the callbacks issue

thosmos19:10:29

yes, it's related

tony.kay19:10:47

@dnolen: (on bug fix): Great, so it does not require rendering the path from root, I take it. Merging non-query props?

dnolen19:10:35

OK good time to listen in … a big-ish change

dnolen19:10:46

affects multiple things

drcode19:10:49

*pricks ears*

dnolen19:10:23

so the fundamental problem is that everyone is trying to put computed properties along with props that go along with queries

dnolen19:10:41

this includes things like callbacks, and edit states and whole host of other things

dnolen19:10:49

currently we’re abusing props for this

dnolen19:10:05

the problem is fundamentally that queries don’t know anything about this stuff

dnolen19:10:32

and then you have to do a bunch of goofy stuff to get it back

dnolen19:10:17

move reads up, duplicate logic (in the case of path optimization you’d have to reconstruct this information since you can’t get it from the parent) etc. etc.

dnolen19:10:03

all these stem from the problem of complecting props

dnolen19:10:03

all these issues issues go away if you decomplect the computed stuff from props

dnolen19:10:33

but Clojure already solved this problem years ago

dnolen19:10:55

leave the data alone, put the information about the information somewhere else

dnolen19:10:20

if you do this then making sure it carries over is simple same as in Clojure

dnolen19:10:32

collection operations preserve metadata

dnolen19:10:43

in Om Next state transitions can preserve metadata too

dnolen19:10:05

dealing with metadata directly is annoying of course so we can just provide a simple helper

dnolen19:10:23

(om/computed raw-props {:edit (fn [e] (om/transact! …)})

dnolen19:10:56

now when you change something with Ident, the other components can rerun their queries and also just copy over computed

tony.kay19:10:30

Questions/suggestions: 1. Have you considered implications of closures over parent? (Not saying anything is wrong...just noting a potential place to analyze) 2. Perhaps add that to the generated factory instead of requiring additional calls?

dnolen19:10:14

I don’t know what 1) means

tony.kay19:10:31

If the thing in metadata closed over something in parent, and you cache it in metadata

dnolen19:10:55

om/computed doesn’t care about closing over anything

dnolen19:10:59

and it doesn’t matter where you use it

dnolen19:10:10

inline, factories, parse … etc. who cares

tony.kay19:10:21

right, but that (fn [e] ...) might have

dnolen19:10:30

you in fact will need to be able to use it anywhere

dnolen19:10:39

let’s not derail on closures

dnolen19:10:43

it’s not relevant to this

dnolen19:10:40

if you’re copying something over the closure can’t possible matter since you got it from the parent

dnolen19:10:46

the parent didn’t rerender so nothing is stale

dnolen19:10:59

if the parent did re-render … nothing is stale

tony.kay19:10:08

that was my initial impression...but the caching aspect just brought it to mind

dnolen19:10:27

copying cannot matter in this case at all

dnolen19:10:32

you can’t be stale

dnolen19:10:58

if you actually needed something from a parent whatever you had is history anyway

tony.kay19:10:33

yep, since it would have re-rendered (and re-called you) when it changed.

dnolen19:10:41

that’s right

dnolen19:10:55

this is only about a child re-rendering without parents knowledge

dnolen19:10:57

it’s safe

tony.kay19:10:48

I see no other (potential) holes

dnolen19:10:47

it’s a huge simplification

thosmos19:10:51

so it's like a component level persistent state store that only exists until the parent rerenders?

dnolen19:10:58

a bunch of problems I would had to have sort through disappear

dnolen19:10:16

thosmos: yep

dnolen19:10:25

but it can move over between state transitions

dnolen19:10:31

and it doesn't eff up queries or parsing

dnolen19:10:48

like what we’re doing today

dnolen19:10:35

the best part

dnolen19:10:44

any code you have now isn’t effected :simple_smile:

dnolen19:10:56

but it means you can gradually fix to eliminate the surprises later

dnolen19:10:38

om/computed om/get-computed ?

dnolen19:10:16

it means the query part of Om Next becomes very pure

tony.kay19:10:40

yeah, I'm loving it more by the moment. Naming...two hard problems in CS

dnolen19:10:59

it’s definitely a big break from React since React uses props for computed stuff

dnolen19:10:12

but it’s just a mess when you’re trying to do this super functional thing that Om Next does

dnolen19:10:41

the big tradeoff is that this stuff isn’t visible at the REPL, will need tooling to see this information

tony.kay19:10:12

computed, dynamic, generated....reading thesaurus

dnolen19:10:32

alternative put this stuff into a special key

dnolen19:10:38

:om.next/computed on props

dnolen19:10:46

then visible and still get the benefits

tony.kay19:10:59

I kinda like that for pragmatic reasons

thosmos19:10:17

or offer both options

tony.kay19:10:18

eh...but ppl might use select-keys

drcode19:10:19

I'm liking that too, though I don't feel I understand the tradoffs very well yet

tony.kay19:10:31

to pare down maps to the stuff the query asked for

dnolen19:10:47

tony.kay: people shouldn’t be doing that though

dnolen19:10:58

that just goes back to people mucking with props you got from query

tony.kay19:10:01

not in the components

dnolen19:10:06

if you do that, you deserve what’s coming :simple_smile:

tony.kay19:10:11

just trying to poke holes :simple_smile:

dnolen19:10:31

@thosmos: not going to offer options :simple_smile:

dnolen19:10:38

we’re doing one thing or the other thing and we’re sticking with it

dnolen19:10:50

I prefer key for visibility

thosmos19:10:05

i like repl visibility over special tooling

tony.kay19:10:10

orthogonal concerns leans me towards metadata, but visibility leans me towards keyword

drcode19:10:12

Oh no, Om Next is becoming an "opinionated" framework :simple_smile:

tony.kay19:10:31

the latter is a tooling issue

tony.kay19:10:49

which we can write a bit of code to address

tony.kay19:10:00

I can live with either one

dnolen20:10:07

ok going to go w/ special key om.next/computed om.next/get-computed unless I hear something better in the next 5 minutes while I code this up :smile:

drcode20:10:31

I think the concept is sophisticated enough that people will be helped by just being able to (print (om/props this)) and see that there's some special stuff in there.

dnolen20:10:32

so one issue

thosmos20:10:39

what about a key on local state? would that make it more clear that it's transient?

monjohn20:10:40

Visibility seems to me to be more important

dnolen20:10:04

@thosmos: visibility problem

dnolen20:10:28

so it seems like we would need to use key or metadata depending on which one is appropriate

dnolen20:10:51

I’m not so worried about the vectors case to be honest

dnolen20:10:04

since that’s nearly always a collection

dnolen20:10:13

which will apply computed to it’s children

tony.kay20:10:09

Yeah, all of the cases I can think of are ok if you just propagate it through

tony.kay20:10:37

oh wait....merge it through?

thheller20:10:53

just wanna throw my suggestion from a few days ago into the mix

dnolen20:10:03

you don’t need to merge

tony.kay20:10:11

each child will be explicit

thheller20:10:14

(a-component query-data {:ref "hi"} ...)

dnolen20:10:16

just read it off old props and add it to the new props

thheller20:10:29

just make query data an explicit param

dnolen20:10:34

@thheller: no changing signatures

tony.kay20:10:58

@thheller: You can always write your own helper function for that (I keep annoying David with the same kinds of suggestions :wink: )

dnolen20:10:06

changing signatures is a disaster for would be templating providers

dnolen20:10:38

keeping om.core/dom and om.next components in sync is just a hard requirement

thheller20:10:18

didn't require om.core require (om/build ...) for everything?

dnolen20:10:30

@thheller: yeah totally busted

dnolen20:10:37

not going back to that

thosmos20:10:57

@tord: re: your earlier question around naming of om.next/Ident, there is om.next.protocols/IIndexer :wink:

thosmos20:10:28

@dnolen: is there any chance of wanting a (defrecord Ident) in the future and then needing to name it something different because of that?

dnolen21:10:22

@thosmos yeah not public

thosmos21:10:15

Ident is nicer on the eyes when getting started and especially for how commonly it's used

tony.kay21:10:48

GraphQL: types, coercion, and introspection...bleh...it's like reading about lions and tigers and bears.

jannis21:10:03

Mmmh, computed props, cool. Now things are cleanly separated. Good idea @dnolen :simple_smile:

jannis21:10:07

Did I read earlier that select-keys is a bad choice for extracting query results for subcomponents? Example: [{:persons (om/get-query Person)] -> (let [persons (select-keys (om/props this) [:persons])] (person-list persons))

tony.kay21:10:36

@jannis: select-keys bad idea in components

tony.kay21:10:00

doing it as an implementation detail in your read/parser are fine, since the computed stuff is applied after

tony.kay21:10:21

e.g. components should not be enforcing query response details

dnolen21:10:32

So this computed this is awesome

dnolen21:10:46

It means we can always path optimize without fear

jannis21:10:10

@tony.kay: Does select-keysdrop meta?

dnolen21:10:13

Will make recursive query support trivial

tony.kay21:10:38

@jannis: no, it drops keys :simple_smile:, and the computed stuff is in a special key for maps

tony.kay21:10:53

he's only using metadata on vectors

tony.kay21:10:20

but implementation detail, so orthogonal to the real point: don't enforce query logic in the UI...which hopefully is obvious

tony.kay21:10:14

@dnolen: recursive queries a la pull-style ...?

jannis21:10:24

I'm not sure how the select-keys example above is any different regarding what it expects than, say (get (om/props this) :persons)... you have to do something like that to extract the props you pass down to children, no?

dnolen21:10:50

I mean recursive components

tony.kay21:10:35

@jannis: that would be fine, in that you're not changing the query result, and you'd still explicitly pass the computed stuff you wanted to pass on to a child. The point is you should not be "filtering" out stuff. Picking a sub-result to pass to a child is fine. It was a pretty narrowly focused example where I was trying to explore where pass-through might accidentally filter out the "computed" data and surprise a developer.

jannis21:10:12

@tony.kay: Oh, of course!

jannis21:10:24

Sure, don't drop keys from the query result that the child is asking for.

tony.kay21:10:08

well, don't really molest the query result at all...getting the response "right" was the parser/readers job.

jannis21:10:24

Yes, yes. Fully agree :simple_smile:

jannis21:10:15

Pass it down, not mess it up. Or something.

dnolen21:10:26

So now that we have computed re-running whole queries is unnecessary

tony.kay21:10:29

ah, right. but still assuming an Ident, right?

tony.kay21:10:10

or is there context you can store there that I'm missing to reconstruct context

tony.kay21:10:00

OH....adjacent items...hrm. no, still not seeing the case, I guess

dnolen21:10:01

Don't need to reconstruct context of you have ident

dnolen21:10:23

Computed properties get copied over

dnolen22:10:05

So pondering world where full query only happens on root renders only

tony.kay22:10:33

right, I got that, but how do you run that deeply nested sub-query without Ident?

tony.kay22:10:42

have to root it on something

thosmos22:10:48

@dnolen: how does the om/computed enhancement address @drcode's example from earlier (https://gist.github.com/drcode/0b4a2917b02b2c54c55b) in which a subcomponent is rerendering itself on a set-state!? Is om going use the computed mechanism to store its previous state and avoid doing another query read?

tony.kay22:10:55

I'm not sure what you keep in that context

tony.kay22:10:50

@thosmos: set-state causes a re-render of a leaf node, and parent "stuff" is lost in the old model, I think...(to be honest, didn't look at that example)

dnolen22:10:14

Right but the query can use the ident as the root of the query

thosmos22:10:54

in drcode's situation, a query read on key :bar is happening on Child's rerender, even though there is no read fn for that key defined and Child has no Ident.

tony.kay22:10:57

@dnolen: I think we're saying the same thing, which is why I was confused

dnolen22:10:51

Will think about this, but I suspect a simplification ahead

thosmos22:10:20

oh i see, his example isn't working because he didn't pass a prop for that key, which would be stored by this computed change?

tyler22:10:03

Sorry to pollute the chat, but I saw someone posted in here how to configure the reconciler for react native and I can’t for the life of me figure it out. Unfortunately it looks like the search goes only so far back and its lost in the history. Does anyone know what to pass in for :root-render and :root-unmount for react native?

tyler22:10:48

Bookmarked thanks @minimal

tony.kay22:10:56

I'm going to echo David's (implicit?) recommendation: Read the Relay docs. I'm embarrased to say I've probably cost myself many hours of head scratching by not just reading the pages at https://facebook.github.io/relay Particularly "Thinking in Relay" and the Mutation page under "Guides"

gmcramm22:10:43

Dumb question, and maybe it's already been answered, but what is the proposed way of adding something to a normalized collection?

gmcramm22:10:06

I'm going through the tutorial pages (just finished 'Components, Identity & Normalization') and was thinking of extending it to add a new person either to one of the lists.

tyler22:10:36

you can call om/normalize on the data you want to insert and then merge that into state

dnolen22:10:39

@gmcramm: def not a dumb question :simple_smile:

gmcramm22:10:51

:thumbsup: Wow thanks!