Fork me on GitHub
#om
<
2016-04-17
>
iwankaramazow08:04:20

@currentoor: there isn't an official way yet

raphael12:04:38

@anmonteiro: after reading this post: http://anmonteiro.com/2016/01/exploration-patterns-om-next-part-1/, I try to launch the code of your gist: https://gist.github.com/anmonteiro/2b282aa35380558a8b1d#file-composite-cljs to understand how recursive queries are working simple_smile but I receive an error "Uncaught Error: No item {:leaf [:id :width :height :color], :composite [:id :width :height :color {:children ...}]} in vector of length 2". can you help me? 😅

anmonteiro12:04:12

@raphael: pasting the code from the gist works for me

anmonteiro12:04:25

which Om version are you using

raphael12:04:28

which om version?

raphael12:04:39

1.0.0-alpha22

anmonteiro12:04:51

right, alpha22 doesn’t support recursive unions

anmonteiro12:04:03

alpha32 is the latest alpha

anmonteiro12:04:15

recursive unions are supported from alpha30 onwards

raphael12:04:23

ahh ok thanks a lot simple_smile working!

iwankaramazow14:04:57

hmm, I might be missing something obvious but you have to manually post-process the result of a remote mutation on the client? (except for tempids) A remote mutation returns something of the shape { 'mutation/key {:value {:keys … :tempids … :result ...}} Should I manually process this stuff to (for example) merge the value of :result under a key stored under :keys ?

iwankaramazow17:04:38

nvm, figured it out 😄

madvas18:04:01

Hi everybody, I made a TodoMVC using Om.Next, Datomic, Datascript and Server Sent Events for real-time sync simple_smile U can find code here https://github.com/madvas/todomvc-omnext-datomic-datascript

tmorten19:04:45

Hello all...I've been doing quite a bit recently with Om.next and was working on patterns for larger SPA development. Has anyone came to the conclusion that if you have a large data tree perhaps loading that all in via remote call isn't the most effective way to go? I don't see any other way at this point since it all comes in via Root (top) level query.

tmorten19:04:20

Essentially, you basically need to remote sync ALL the data they could ever get to in the application when it initializes. If you are only using, one RootView which from how I've seen people implement routing in SPA only use one top level root and flip in and out main components when routes change...

iwankaramazow19:04:10

@tmorten: I hope you only fetch things that are on screen 😉

iwankaramazow19:04:17

(unless you need to prefetch stuff)

symfrog19:04:32

@tmorten: Are you aware of http://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/ ? If you use the set-query! approach then you would be able to create remote queries that only pull the data required for the current route.

tmorten19:04:47

I have read this...and I think this is interesting however, your top level keys have to align with your "routes"...

iwankaramazow19:04:09

@tmorten: I'm implementing a router atm, there isn't a way around out.

iwankaramazow19:04:27

Have given it a lot of thought, things need to compose with arbitrary joins...

tmorten19:04:17

I too have implemented a router solution, but mine essential swaps the "root" with a new root view. Problem is that it forces you to reload the entire view, i.e. navigation, menu, footer, etc...

iwankaramazow19:04:49

Do you have nested routes?

tmorten19:04:59

I do...quite a few of them

iwankaramazow19:04:31

you implemented a merge-with into at merge-tree on the reconciler ?

iwankaramazow19:04:09

i.e. `(merge' [a b] (merge-with into a b))`

tmorten19:04:35

I've seen that but seems like I'd have to do that for every child element

iwankaramazow19:04:12

Not sure I'm 100% following, what do you mean by reloading the entire view?

iwankaramazow19:04:20

Your state resets?

iwankaramazow19:04:04

ComponentDidMount fires every time on all components when you change a route?

tmorten19:04:32

Obviously, RootView has its own query

tmorten19:04:11

and inside render I call all of the fun stuff to display navbar footer, etc...

iwankaramazow19:04:35

I'm not 100% sure, but the add-root! might be the problem..

iwankaramazow19:04:57

The new root might replace the previous one

iwankaramazow19:04:05

if it instantiates a new reconciler every time

iwankaramazow19:04:12

that would explain the problem

iwankaramazow19:04:24

or it might not 😛

tmorten19:04:06

I think it is the problem...however, I would essentially like my components to remote "query" their own data, but can't do that since it has to happen at the Root

tmorten19:04:16

Only thing I have seen is trivial examples that don't have a large graph of data

iwankaramazow19:04:38

My router (alpha version) is almost finished

iwankaramazow19:04:52

Give me 4 days, and I'll open source it

tmorten19:04:26

which is what I've been working on

iwankaramazow19:04:38

I started basically with the same

tmorten19:04:02

I'd still like to keep a good "graph" locally though

iwankaramazow19:04:32

Can you explain ? I'm not 100% following

tmorten19:04:02

These seem to follow: :route/data top level element

tmorten19:04:06

or :page/data

tmorten19:04:49

that's where my parser begins to read...but what if my actual top level element is :user/inventory

tmorten19:04:08

:user/inventory -> inventory/products -> and so on

tmorten19:04:49

Seems like I still need to pull in all of the children from :user/inventory as I follow down the path

iwankaramazow19:04:55

Ah you mean everything is merged under :route/data?

iwankaramazow19:04:11

call the parser recursively

iwankaramazow19:04:42

(defmethod read :default
  [{:keys [parser query state] :as env} key params]
  (if (some #{key} [:app :home :test :union])
    ;; recursively call the parser,
    ;; i.e. we ignore :app || :home || :test || :union
    ;; and walk a little deeper in the query
    {:value (parser env query)}
    {:value (get @state key)}))

tmorten20:04:00

I see...but wont you still need pull in the children from :user/inventory

tmorten20:04:06

if I was going to go into /inventory/1/products/10

tmorten20:04:26

remotely that is

iwankaramazow20:04:50

depends on the structure of the root query

iwankaramazow20:04:37

I mean you probably have something like [{:some-page {:inventory [:stuff]} {:products [:other-stuff]}}}]

iwankaramazow20:04:56

if you parse recursively at :some-page

iwankaramazow20:04:07

it will dispatch on both :inventory and :products

tmorten20:04:32

But could I have this: [{:some-page {:inventories [{:products [:id :name]}]}}]...?

tmorten20:04:07

That would essentially be my datomic pull...

tmorten20:04:24

I think that is the source of my issue -- since on the inventories screen, I don't need to see the products, but I am loading every product from every inventory since I am pulling in EVERY product from EVERY inventory

iwankaramazow20:04:53

declare the things you want

tmorten20:04:38

Thats when I am guessing I need the special merge function, correct?

tmorten20:04:55

to merge those products under the correct inventory

iwankaramazow20:04:03

it depends, it might come in handy the merge those results under the keys you want..

symfrog20:04:57

Does a call to set-query! update the indexer when keys are added or removed to a component's query expression? It seems that a component is only indexed under the static class query expression keys and that attempting to do a transact! with a re-render key only works if the key is present in the query's static class query. Is there any way to get a component to re-render if it's query has been modified via set-query! (e.g. adding/removing keys) and the key to be re-read is different or may not exist in the static class query?

anmonteiro20:04:24

@symfrog: set-query! calls re-index

symfrog21:04:49

@anmonteiro: thanks, most likely an issue on my side then

tmorten21:04:09

Thanks for the help @iwankaramazow