Fork me on GitHub
#om
<
2015-12-16
>
jimmy02:12:22

@wilkerlucio: nice poster 😄 He looks like a legendary in a movie xD

wilkerlucio02:12:25

@nxqd: hehe, I found it very cool too, I believe it was made by the cognicast team

wilkerlucio02:12:11

it reminds me of final fantasy, like an old FF 7 poster

iwillig04:12:52

I am trying to use om.next with a remote. My initial data is an empty atom and I am using datomic on the backend. I have a root component, a list component and a item component. When I pass normalize = true to the reconciler my item component is just passed the identity, not the full object. I know I am missing a key concept but I just can’t figure it out

iwillig04:12:21

Do I need to provide a read function that goes from a ident to a full object?

jetmind09:12:00

@iwillig did you try to use om/db->tree in your read function?

jetmind09:12:12

It will save you from resolving idents manually

hmadelaine10:12:22

Hi everyone ! Is it me or the tutorial “Thinking with Links!” is broken ? I remember it was working weeks ago. I have the impression that om/tree->db ignores the :current-user key in the init-data

griffio11:12:16

@hmadelaine: Seems ok for me on 28/29-snapshot - the only thing I had to fix was a missing nil -> " (dom/div (dom/h2 nil "A List!”)”. But that is cosmetic. 👌

hmadelaine11:12:23

:thinking_face: thanks @griffio. I will investigate further then

griffio11:12:05

@hmadelaine: I take it you meant “db->tree” and not “tree->db”, the “Thinking with Links!” uses "db->tree”. Just in case you have it reversed 😀

hmadelaine11:12:04

@griffio: I was referring to the implicit tree->db in the add-root!

griffio11:12:09

@hmadelaine: Ok - let me know if want me to confirm anything that you may be seeing. Happy to check 😇

pyr12:12:47

Hi everyone

pyr12:12:06

When playing with an om.next parser by hand, I'm struggling to find the best way to express a query for a specific item

pyr12:12:39

To be a bit more clear, supposing i'm working with the denormalization tutorial at https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-Normalization

pyr12:12:57

how would i query for a specific name?

dnolen13:12:35

@pyr: what do you mean?

pyr13:12:34

@dnolen: playing with the parser i can easily get a list of entries as described in the tutorial:

pyr13:12:53

(parser {:state st} '[:list/one])

pyr13:12:57

or generate mutations

pyr13:12:17

the ident of a Person is [:person/by-name name]

pyr13:12:37

but if I query (parser {:state st} '[[:person/by-name "foo"]]) i cannot access that entry

dnolen13:12:03

@pyr so do you mean a person’s name via ident?

dnolen13:12:26

if so that can work

dnolen13:12:48

as to your ident example not working, that just sounds like a bug in your parsing

pyr13:12:24

the error I get back is Error: :task/by-id is not ISeqable

pyr13:12:36

(here :task/by-id is the equivalent of :person/by-name)

dnolen13:12:44

none of this is informative

pyr13:12:46

a bug in my parsing sounds likely simple_smile

dnolen13:12:50

it can work, you have a bug somewhere simple_smile

pyr13:12:55

yup, thanks.

pyr13:12:08

just wanted to make sure I didn't misunderstand the ability

pyr13:12:13

@dnolen: maybe one last clarification, you're saying "a person’s name via ident?"

pyr13:12:03

my understanding was that by querying an "ident" i would get back the results of what I expose in om/IQuery as component fields

dnolen13:12:22

@pyr not sure why you think that

pyr13:12:10

I understood om/IQuery (query [this]) as "this is what I need", and om/IIdent (ident [this]) as "this is how to get to it"

dnolen13:12:55

@pyr I still don’t know why you think that

dnolen13:12:08

this is not expressed in this way anywhere in the documentation around queries or ident

dnolen13:12:45

your understanding about query OK

dnolen13:12:53

but it’s relationship to ident and what it’s for, no

pyr13:12:51

i'll read the doc again

dnolen13:12:04

ident is just about identity

dnolen13:12:32

it’s a way to know that components map to the same logical entity vlaue

dnolen13:12:44

it also serves as way to normalize data tree

dnolen13:12:17

and finally it serves as a way to query identities

pyr13:12:25

this i got, but since ident is f(props) => id

pyr13:12:03

i inferred it was bijective

a.espolov13:12:24

@dnolen: ident is unique value for identification component?

dnolen13:12:48

@a.espolov: I don’t know what you are asking

a.espolov13:12:49

and nothing more

dnolen13:12:56

multiple components can have the same ident

dnolen13:12:09

components of completely different types can have the same ident

pyr13:12:36

and might thus need different props

pyr13:12:32

so based on that ident, the parser is able to return the full props for the corresponding item, right?

pyr13:12:34

s,props,dataset

dnolen13:12:41

the parser doesn’t do anything

dnolen13:12:47

you provide the semantics

pyr13:12:09

yes, there read implem in the parser.

pyr13:12:18

sorry about the semantic shortcuts

dnolen13:12:21

so it’s your problem to sort all of this stuff out

dnolen13:12:08

it should be clear that how parsing works today is completely pluggable

dnolen13:12:19

parse is just a function of three arguments

jannis13:12:28

@pvr: The ident states which data a component represents but the parser only processes the query (of the root component).

jannis13:12:47

You can have idents in your query but it's up to you to implement :read in the parser so it resolves them into the actual data they represent, e.g. by normalizing your data with db->tree or by using things like (let [st @state] (get-in st (:some-ident params))).

pyr13:12:15

the responsibility to implement read for idents i get

dnolen13:12:49

@pyr sorry for being pendantic

dnolen13:12:58

these things need to be kept clear

dnolen13:12:03

otherwise everyone gets confused

pyr13:12:09

no worries

pyr13:12:38

@jannis: well understood

pyr13:12:45

@jannis: and I have this

pyr13:12:07

I'm left with a bit of studying on the actual semantics and one practical problem

pyr13:12:51

@jannis: (by I have this, I mean, i have read implems for mhy idents to go look-up the needed data)

a.espolov13:12:50

It turns out I have to specify the root components all queries that will be used in the child components?

jannis13:12:22

@dnolen: I haven't followed the news closely - did anything happen on the path optimization front yet? I'm using db->tree on an app state with about 40 linked entities, with up to 4-5 levels of recursion via '... and the query takes about 150ms. Even with memoized db->tree it takes about the same. I wonder how I can optimize this and where the majority of query time is most likely spent.

dnolen13:12:39

@a.espolov: in the sense that the root component has the total query only

dnolen13:12:28

@jannis yes memoization won’t be enough you need to dig into path optimization

dnolen13:12:42

@jannis the ’… devcards example in Om repo demonstrates how it works

a.espolov13:12:08

@dnolen: It turns out even if I need a list of cities. Data will still be sought by the parser?

dnolen13:12:31

@a.espolov: you should re-read what I’ve been saying

dnolen13:12:45

also a question like that is covered in the existing tutorials

jannis13:12:35

@dnolen: Thanks, I'll take a look!

denik13:12:31

If a component uses :db/id as its key-fn, where and how should I look for it? I assume in the indexer?

dnolen13:12:38

@denik :keyfn is about React not Om Next indexing

denik13:12:48

so dom/node?

dnolen13:12:12

let me look

jannis13:12:03

@dnolen: Did you mean the norm-tree-read example?

dnolen13:12:46

@jannis note reconciler takes :pathopt true

jannis13:12:32

Ah, that's the bit I didn't notice. So that allows to make use of read :node/by-id?

jannis13:12:44

Or is that a separate feature/optimization?

dnolen13:12:50

@denik see react-ref

jannis13:12:16

Right, with :pathopt true it complains if there is no read :node/by-id implementation. Makes sense.

dnolen13:12:14

@jannis right but this goes back to my point about parse which people really need to think about simple_smile

dnolen13:12:21

parse is just a function

dnolen13:12:35

the whole read mutate split is just something I came up with as an expedient

dnolen13:12:39

it is not fundamental

jannis13:12:56

And I know I don't have to use db->tree if normalizing is too costly.

dnolen13:12:09

the way :pathopt true actually works is the following

dnolen13:12:23

parse gets invoked once with an ident

dnolen13:12:45

if this returns nil, it will get invoked again with a root query

dnolen13:12:02

so this means you can supply a parse that wraps the real parse

dnolen13:12:12

that checks if the ident is something you actually want to handle

dnolen13:12:26

functions!

dnolen13:12:28

like magic!

jannis13:12:33

Hehe, woooow

jannis13:12:11

Also, the fact that it was complaining that read :node/by-id was not implemented is just a result of using defmulti, which obviously has nothing to do with Om itself.

dnolen13:12:36

yes and also the questions that @thomasdeutsch and @tony.kay have are really addressed by this

dnolen13:12:43

eventually people will just want more power out of parse

dnolen13:12:51

and Om Next doesn’t need to be involved in that

denik13:12:11

@dnolen: hmm I’m not sure this helps. I want to lookup a component based on db/id and call an instance-method on it.

jannis13:12:15

Ok, already got pathopt working with an ident-based read in parallel to this discussion and it is blazingly fast. simple_smile

jannis13:12:53

It's literally the same as in the example, except I use :node, not :node/by-id. 😉

dnolen13:12:02

nice to see all this up front work / planning is serving us well simple_smile

jannis13:12:32

Funny. At the top level, the ident-based "shortcut" is still slow but one level further down it's near instant. But I guess that makes sense - the further at the top you read, the more work db->tree still has to do (if you use it, that is).

jannis13:12:02

There's no warning about slow ident-based reads though, unlike with other queries.

pyr13:12:06

I think i got to the bottom of what I was after. If using a parser built from om/parser and dispatching with a defmulti based on om/dispatch, when querying for '[:entity/by-foo "entityid"] I wasn't able to figure out where "entityid" was fed. apparently it's in the :query-root field of env.

dnolen13:12:40

@pyr yes if you supply ident :query-root will be set to that

denik13:12:19

@dnolen: is there a top-level way to lookup the component based on its db/id from props?

denik13:12:31

regardless of react-ref..

dnolen13:12:42

@denik this is what Ident is for

denik13:12:13

@dnolen: thanks! I think that will do! Using datascript and was under the impression Ident would not be necessary

dnolen13:12:43

@denik the other thing is that the indexer is now pluggable (not yet in a release)

dnolen13:12:02

so that’s another route in the future

denik13:12:48

@dnolen: okay, very much looking forward to it simple_smile especially for tooling thx

hmadelaine14:12:43

@griffio: I have cleaned my repository, pull a fresh copy of Om 29-SNAPSHOT but still did not managed to make tutorial “Thinking with Links!” to work. I tried with 28 it does not work. But with 27 it is OK @dnolen : any obvious reason why it is broken since 28 ? Thanks

dnolen14:12:50

but can you be more clear than “does not work"

dnolen14:12:53

is there an error?

pyr14:12:14

ah, never saw that one, thanks @hmadelaine

hmadelaine14:12:33

@dnolen: the current-user email does not show up

dnolen14:12:59

@hmadelaine: ok, will have to take a look later

hmadelaine14:12:32

@dnolen: I have the impression that om/tree->db ignores the :current-user key in the init-data

dnolen14:12:14

@hmadelaine: there were some other fixes so that support may have regressed, will make sure there is a test to cover this regression when I fix it.

hmadelaine14:12:53

@dnolen: Ok, thanks. I have done this tutorial again after listening to the excellent http://blog.cognitect.com/cognicast/093

hmadelaine14:12:17

Hi @pyr ! You enjoy doing some Om.Next 😉

pyr14:12:42

yes, there are some things our om projects would clearly benefit from

andrewhr14:12:39

such cover, very album, much itunes cc @dnolen

dnolen14:12:10

haha came out nicely, lucky to have Michael Parenteau work on these

hmadelaine14:12:35

Yes, Michael Parenteau is a great artist !

txus16:12:25

I’m seeing something interesting

txus16:12:23

I’m seeing correct normalization in (om/tree->db RootView init-data true), but incorrect on read (`@state` is wrong). It must be that a mutation I’m doing messes up the tree, yeah?

dnolen16:12:59

@txus maybe, sounds really simple to test that hypothesis

artemyarulin16:12:22

@dnolen: Could you please have a look on issue that we have with React Native + Om-Next ? https://clojurians.slack.com/archives/cljsrn/p1450276969001160 TL;DR: Om-Next using React global in 3 places. RN doesn’t use any globals, but works though modules require. If we would be able to configure those 3 places and pass RN functions we would eliminate any hacks with global creation and advanced compilation

dnolen16:12:04

@artemyarulin: OK but this doesn’t seem very important or hard to work around

dnolen16:12:16

goog.global exists for a reason

dnolen16:12:16

the real fix would be a better import global name story for :foreign-libs

dnolen16:12:28

that’s about the only thing I would actually consider

dnolen16:12:09

so somebody could fix the real root issue and then I would be happy to switch that.

dnolen16:12:20

not interested in quick fixes on my side when quick fixes exist downstream

artemyarulin16:12:20

Got it, thanks

anmonteiro16:12:39

just pushed a lein template for Om & Om Next based on the architecture I've been using, hope it's helpful for others

Tim17:12:02

I’ve been looking for something similar

chris-andrews19:12:41

Should it be possible to transact! against the reconciler and provide an Ident that needs to be re-read, and have all components with that Ident re-render?

dnolen19:12:08

@chris-andrews: that should work yes

chris-andrews19:12:20

@dnolen: Awesome, thanks. I am currently trying and failing, but I think my read functions are to blame. Just wanted to make sure I wasn’t after something that isn’t intended to work

joshfrench21:12:27

is the Thinking With Links tutorial out of date? the example code doesn’t seem to read [:current-user _] at all

dnolen22:12:29

@joshfrench: issue already been reported

dnolen22:12:33

will take a look later

tony.kay22:12:19

@dnolen: db->tree seems ok with respect to [:k _] idents. Just ran (and even embellished) tests on tip of master

dnolen22:12:38

@tony.kay: yeah I see we have tests for this

dnolen22:12:43

putting the tutorial into a devcard now

dnolen23:12:10

@joshfrench: I copied and pasted the tutorial into master - works fine