Fork me on GitHub
#om
<
2015-11-09
>
drcode02:11:50

@thomasdeutsch: In my eyes, the appeal of Datascript boils down to how similar you want the structure of your data store to be to the structure of the UI... Part of the appeal of "query selectors" is that the UI and data store can be quite different in structure, but the benefits of Datascript in an Om Next app are at their greatest if the difference in structure between UI and data store is relatively small.

escherize03:11:10

;; transcribed om next screenshot
[:some/key]                            ;; prop
[(:some/key {:arg :foo})]              ;; prop + params
[(:some/key [:sub/key])]               ;; join + selector
[({:some/key [:sub/key]} (:arg :foo))] ;; join + params
[[:foo/by-id 0]]                       ;; reference
[(fire/missiles!)]                     ;; mutation
[(fire/missiles! {:target :foo})]      ;; mutation + params

grav07:11:39

Does Om.now has something similar to statics in React? https://facebook.github.io/react/docs/component-specs.html#statics

grav07:11:34

I want to be able to see the ‘type’ of an instance of an Om component, and I thought that was a way of doing it. Any other suggestions are welcomed

thomasdeutsch08:11:43

i started to use datascript simply because in many components, i needed to get state that can be found on multiple locations - and there are many problems connected to this issue.

thomasdeutsch08:11:19

a sample app: a todo-list application, and every todo-item has a "tag" input where you can select from given tags like "important" or "later". the list of tags is a global entity (not part of the todo-list or item).

thomasdeutsch08:11:24

@dnolen: maybe it was not a good idea to allow this query to work [:a/name {:a/b [:name]}] without a reader for :a/b to be required.

thomasdeutsch08:11:38

(for datascript)

hmadelaine08:11:53

@dnolen: thanks for the recursive queries, I am going to study it today

dnolen12:11:35

@hmadelaine: not quite done yet simple_smile

dnolen12:11:06

still sorting through update issues and recursive queries fundamentally need path optimization support

dnolen12:11:30

none of this difficult but I would wait till get these bits wrapped up and tested

dnolen12:11:38

and I will likely write up a corresponding tutorial

dnolen12:11:01

@thomasdeutsch: whether a query will or won’t work is not something Om Next is involved in. That’s entirely up to you.

dnolen12:11:08

otherwise it couldn’t be pluggable

dnolen12:11:26

@grav I don’t see how types and static have anything to do with each other.

grav12:11:06

@dnolen: type in quotation. I just want to find out, whether a component has a certain characteristics. I could use React’s statics for this, but I cannot find anything similar in Om.now

dnolen12:11:22

@grav there’s no supplied sugar for defining static methods. but you could supply such sugar yourself this is how defui works in Om Next.

hmadelaine12:11:49

@dnolen: thank’s for the advise 😉

rarous13:11:47

Hi, I’m trying Om.next and I’m curious if (get (om/props this) :children) should work or am I doing something wrong?

dnolen13:11:42

@hmadelaine: so one thing I’m wondering is whether the generalized recursion thing is worth pursuing, it would add a lot of complication over the support for Datomic Pull

dnolen13:11:13

the obvious problem is that recursive om.next/get-query will result in StackOverflow

dnolen13:11:04

@rarous: we don’t support accessing children directly

dnolen13:11:18

@rarous and no that isn’t supposed to work

dnolen13:11:47

@rarous: and that’s not completely true, there’s a private fn get-children

dnolen13:11:56

I could be convinced of making it public

rarous13:11:56

I don’t think it is necessary. It can be done better on my side.

dnolen13:11:35

I must say it is pretty cool

dnolen13:11:08

it means stuff that's normally tricky, like threaded discussion UI is kind of trivial in Om Next esp. if you throw Datomic into the mix.

hmadelaine13:11:23

@dnolen: I am going to think about that. For the moment I have used DataScript to store my recursive nodes and Marked the children as “component” to bypass the lack of declarative recursive Query. It works well to represent the data. But fails as we expect if I send a mutate action from a child node. Maybe it is not worth pursuing if only me and @mhuebert ask for it

dnolen13:11:23

@hmadelaine: hrm wouldn’t the mutation bit be covered if you can intercept the transaction?

dnolen13:11:59

@hmadelaine: the other reason I’m kind of lukewarm about the generalized recursion thing is I don’t really see how to make it work for sending across the wire.

hmadelaine13:11:48

@dnolen: I am going to try the interception as you suggest

hmadelaine13:11:55

@dnolen I have to try Om-Next with a backend

dnolen13:11:26

@hmadelaine: hrm I guess the backend bit could be made to work if there was support for naming queries … but that’s a whole other complication

hmadelaine13:11:16

@dnolen: so now that the basic recursive queries with mutation works in master, I can study it ? And try it with DataScript ?

dnolen13:11:17

@hmadelaine: the bigger issue is that neither Datomic nor DataScript support this anyway

dnolen13:11:31

so you would be on your own if we introduced syntax that they don’t support

dnolen13:11:51

@hmadelaine: yes please try it out

thomasdeutsch13:11:32

@hmadelaine: i would love to see a small example in datascript

dnolen13:11:44

@hmadelaine: so far my hunch is that the component trick + Dataomic DataScript local recursion can be made to work for most problems.

hmadelaine13:11:15

@dnolen: you are right, I did not think about the syntax problem.

dnolen13:11:04

@hmadelaine: I am fixing the tx intercept stuff right now

dnolen13:11:37

so if a parent intercepts a transaction it becomes the handler

dnolen13:11:11

this should give you enough context to do what you need to do

dnolen13:11:39

and you can of course pass up any information the parent might need to make the transaction precise

hmadelaine13:11:02

@dnolen: great ! It should work simple_smile

dnolen13:11:08

i.e. break down the transaction into specific operations directly on the reconciler

dnolen13:11:22

to avoid over-rendering

dnolen13:11:57

@hmadelaine: fix applied to master it may (probably does) need some tweaking - so feedback is welcome

hmadelaine13:11:53

@dnolen: thank you very much ! I am going to roll up my sleeves and try it

dnolen14:11:14

released 1.0.0-alpha19 with recursive query support

hmadelaine14:11:05

@dnolen: the example I have set up with DataScript now works out of the box with the support of recursive query. simple_smile

hmadelaine14:11:24

@dnolen: you are awesome !

bplatz14:11:21

Quick question on re-rendering logic so I understand intended behavior. If component A has two children, A-1 and A-2, and component A initiates a transact!, I know it will re-render. Do A-1 and A-2 always re-render, or is an equality check on their props done to determine if they need to re-render?

bplatz14:11:27

In om.next, that is.

dnolen14:11:55

@bplatz: there will be an equality check on props and state

martinklepsch16:11:25

Can someone explain the reasoning for mutations to modify atoms instead of being pure and hiding the actual statefulness?

dnolen16:11:32

For what purpose. Also mutations don't have anything to do with atoms. Any state transition.

dnolen16:11:17

Which means there is no acceptable return value

jdubie16:11:42

@dnolen how did you decide on the idea that om should builds up a denormalized tree and is passed down from the root via props. i think relay’s approach is closer to each component is wrapped in a magic container with queries that keeps it in sync. is this a correct assessments of a difference? curious what tradeoffs you weighed there.

dnolen16:11:52

@jdubie: that assessment is not accurate. We work just like relay

dnolen16:11:35

Relay must also normalize, and defui is in fact relay container

jdubie16:11:16

ok got it.

dnolen16:11:38

The primary difference from relay is functional first. And we can run queries on client or server a la Falcor.

mdaines17:11:51

Getting Started Question: I’m getting

Uncaught TypeError: Cannot read property 'force_children' of undefined
when trying to work through the om.next Quick Start. It happens with the code in the “Your First Component” section (and all sections after that I’ve tried).

mdaines17:11:40

Hmm, resolved this ^^^ problem by blowing away the resources/public/js/ directory.

dnolen18:11:19

@mdaines: you usually need to clean if you upgrade your dependencies

mdaines19:11:31

Yeah, I think I had the problem because I tried to use the latest cljs, but then hit a build problem (`No such namespace: cljsjs.react`), and it was easier to step back to the previous version.

mdaines19:11:54

Also, this is my first time playing with cljs, really, so didn’t realize lein clean wouldn’t clear out the compiled files.

dnolen19:11:19

yeah you need to specify :clean-targets

mdaines19:11:23

Cool, thanks.

iwillig19:11:44

@dnolen: do you envision the tempid api for om.next to be similar to datomic’s tempid api? In the sense I can use a tempid every where a real id can be used in an transaction. Then i transact and all references to that tempid is replace with the real id?

bplatz19:11:10

Repost from my accidental post in #C03S1L9DN :

bplatz19:11:11

Is there a function to get a list of components that will re-render with a given query? i.e. which components will re-render based on :a-query in: (om/transact! '[(foo {} [:a-query])]

dnolen19:11:43

@iwillig: that’s the basic idea yes, but specifics will not be much like Datomic or DataScript

dnolen19:11:52

@bplatz: no and you don’t need it

dnolen19:11:02

the keys following the mutation are what cause re-renders

dnolen19:11:12

not the actual mutation itself

bplatz20:11:30

I'm interested in it for troubleshooting. I have a component that sometimes re-renders for the same transaction. So I was trying to narrow down the problem, I wanted to be sure om.next had it as a component it would re-render based on that key to rule out that as a possible problem.

bplatz20:11:17

And the key, i.e. :a-query will trigger a re-render no matter how deeply nested it is in the query/component hierarchy assuming recursively parsing got us to that key at some point?

dnolen20:11:51

@joshfrench: fixed your bug sorry for the delay

dnolen20:11:36

@bplatz: as I said there’s no such thing as mutations triggering re-renders

dnolen20:11:43

I believe what you want already exists

dnolen20:11:52

which is a way to determine what component are listening on what keys

dnolen20:11:01

see om.next/ref->components

bplatz20:11:03

@dnolen: Yes, exactly what I was looking for thanks. The docs threw me as the example appeared to focus on Ident.

dnolen20:11:41

@bplatz: I clarified the docs

joshfrench20:11:43

@dnolen: just spotted that, thanks!

dnolen20:11:52

massive props to devcards

dnolen20:11:20

the combo of Figwheel + devcards & Node.js REPL + cljs.test is one of the best testing combos I’ve ever used

joshfrench20:11:28

++ i tried out devcards on this project and just the act of isolating a component from its parent immediately surfaced all the assumptions i’d made

jannis21:11:40

@dnolen: The selector part of (remote) queries should be applied server-side, right? I.e. filter fields on the server and don't send the ones not requested back over the wire.

dnolen21:11:50

@jannis yes though it’s again up to you to maintain the contract

jannis21:11:00

Ok. I'm asking because if you have (om/transact! this '[(app/do-something ...) :items/list]), it means that the server-side parser will receive an empty selector for :items/list. Am I assuming correctly that I have to repeat the full queries when passing them to transact!? That is, if the component query would be [{:items/list [:db/id :item/name]}], :items/list would not be enough to send the same selector to the server?

jannis21:11:12

(I hope the question isn't too convoluted)

dnolen21:11:40

@jannis not convoluted

dnolen21:11:07

yeah you will would have to specify what you want to re-read

dnolen21:11:54

automating that is probably worth thinking about

dnolen21:11:42

but you should have all the tools to accomplish this yourself for the time being

jannis21:11:58

Automating or providing a shortcut to reusing parts of the component query for transact!. Especially when dealing with long queries (e.g. [... ({:items/list ~(om/get-query Item)} {:foo ?foo :bar ?bar})]) it'll be tedious to repeat them in all transact! calls.

jannis21:11:24

But yeah, I can work with that for the moment. A simple helper function to generate a sub-query like that will do.

dnolen21:11:29

@jannis: will consider this when the other things are out of the way

jannis21:11:51

Sure, thanks simple_smile

rafd22:11:56

Does anyone know the 'correct' way to pass multiple collections to a sub-view in Om Next? I've read and implemented 'Queries with Unions' in another case, but (I think?) this is different. For example, I have a SubView that expects two collections, set up as follows, but I get a "No queries exist..." error when I transact.

SubView 
Query
{:foo/all [...]
 :bar/all [...]}

AppView 
Query
{:foo/all (:foo/all (om/get-query SubView))
 :bar/all (:bar/all (om/get-query SubView))}
Render
(sub-view (om/props this))

dnolen22:11:15

@rafd: that query looks strange

dnolen22:11:46

subselecting queries from a subview is not a thing

dnolen22:11:09

as a general rule a component’s query can only be a vector

dnolen22:11:18

the only exception are unions

dnolen22:11:26

and grabbing a piece from a union is not a thing

dnolen22:11:50

so what you have just isn’t going to work

rafd23:11:58

Thanks @dnolen, I figured I was doing something strangely. I can solve my problem in other ways.

dnolen23:11:26

path optimization landed, simple to speed up your queries signficantly

dnolen23:11:37

will probably roll details into the recursive query tutorial