looking for advice if anyone has a minute https://gist.github.com/selfsame/2c7035a5f5f76ab72d6b

(query [this] 
    `[{:panels `{:outliner (om/get-query Outliner)
                 :selection (om/get-query Selection)
                 :menubar (om/get-query Menubar)
                 :query (om/get-query Query)}}])

and then the component view has an Ident [:panel/by-id <the id>]

actually nvm I got no idea

@hueyp: hmm thats how the examples for unions work, will give it a try

I’m not sure what the union is doing though since they have the same ident which is making me think I don’t understand unions

@hueyp: yeah me neither. Looking at the demo, perhaps a union needs its own intermediary component with an ident that matches the type key https://github.com/omcljs/om/wiki/Queries-With-Unions#the-queries

This weekend I want to give om.next another try. Last time I was stuck at returning errors from remote mutations. So my question is Is there a way to return errors from remote mutations ? If not how are other people handling these use cases e.g. login failure or update with validation errors ?

@selfsame: by generating the query expression you’re dropping metadata which causes Uncaught #error {:message "No queries exist for component path (fp.subdivide/Main fp.subdivide/Panel comp.outliner/Outliner)", :data {:type :om.next/no-queries}}

it should still work however

heya @denik, yeah the original example has subcomponent paths like [:data :outliner] and lets me transact or set-query! on the subcomponents

I think Idents are used to normalize nested state and not again until remote updates get merged in

aren't they also used for transact! updates?

I believe they aren't

which is why you have to #(swap! state update-in [:panel/by-id 5] f ) as your action thunk

aaah ok I was mixed up

idk I'm going to try not using a union and see if I can get better paths

small detour, I think every dev here could make use of: https://github.com/binaryage/cljs-devtools

@selfsame: hope it works out!

Has anyone here used Firebase as a backend DB for Om Next? On first look, it seems like it would mainly consist of parsing the query AST and translating it into firebase queries.

Hey is there any advantages to using multi methods for our read and mutate functions as opposed to using core.match for example?

There is no more IInitState in om.next, correct ?

I am trying to structure a login or register component, I have the following questions : - Should I have :user {:email "" :password "" ...} OR :user/email :user/password OR something else ? For now I have the first approach :

onEmailChange (fn [e]
      (om.next/transact! this '[(user/update {:email ~(-> e .-target .-value)}) :user]))

(defmethod mutate 'user/update [env key params]
   {:action (fn [] (info "What should it do here ?")) })

You would pass the username and password in params.

In mutate function update the state with them.

ok - then for the onSubmitLogin I should make another mutate with :remote ?

I got no experience with remotes 😞

No problem me neither. I am just trying to see what is the tool to use in this case.

Thanks for your help, again.

A swap! statement in the action. Because your data is normalized it is flat so that should be easy.

ok I'll try that thanks

@denik re: component Idents, turns out they do work in transact! if you turn on :pathopt in the reconciler https://gist.github.com/selfsame/2c7035a5f5f76ab72d6b#gistcomment-1690135

@selfsame: thanks, good to know!

Is there any reason to implement om.next/Ident when using Datascript as a data source?

@stuartsierra: yes, idents are used to keep components in sync

also idents can still be used to speed up queries even if you use DataScript

@dnolen: Thanks, makes sense.

@thosmos: haven't tried it yet, but I do think Om-next would work great with a Firebase backend. Firebase data tends to be denormalized and I think Om-next would help a lot with managing it.

@adamkowalski: I've been thinking about using core.match as well. Surprised more people haven't mentioned it.

Still learning here: suppose I have a query that pulls data from a Datascript database. Some of the keys in my query are attributes in the database, other keys represent data I want to compute on-the-fly. if my understanding is correct, my read function has to filter out the "special" (computed) keys, call Datascript to query the "normal" keys, then call some custom code to evaluate the "special" keys and merge them into the result.

Is that headed in the right direction?

@stuartsierra: I would minimize that as much as possible, doing that will make everything a lot more complicated

regardless of DataScript or not

Okay

the only time you should immediately reach to create some synthetic key is the case of a collection you intend to render

that may or not map to something in your data store :user/todos or whatever

in other words, only use synthetic keys for top-level queries?

yes - it’s not that doing things differently isn’t possible

it’s just that at that point you might as well just completely re-implement parse yourself

and dispense with the read mutate pattern which is just a convention

I see.

I suppose anything that I would generate for a synthetic key could just be loaded into the database beforehand.

if for some reason you decide to go down that path that’s what the query AST stuff is for

the cases where you just want to implement your own query evaluation thing

normally that’s narrowed to customizing remote queries, but you can generalize it

@dnolen: OK, Thanks.

So I have my root component with top level queries, and now I have to pull the correct data out of props to pass to each child component. Not too bad, but suppose I want to handle this in a more generic way - couldn't I just iterate over all my child components, call get-query for each, and then call parse passing it the components query and props? Kind of like how in Datomic you can run queries against :db-after after a transaction. Or is there an easier way that I'm missing?

@mdhaney: not really possible and would be going against the grain

@stuartsierra: I do this by having a multifunction for my merge-tree and merge-ident. If certain keys are incoming I will add extra datascript attributes to them at that point. Then my query is always clean.

i.e. I have a made-up datascript-only attribute called :this/user?... basically it takes standard user entity datoms and adds that to it, if the query key was [:this/user '_].

Then my read for that key can query where :this/user? is true.... but that attr doesn't sit obviously in my back-end datomic data store.

And for items that truly need to be computed at run-time, I just do that inside the component using om/computed

@bplatz: Thanks. What are merge-tree and merge-ident?

Those are supplied to your reconciler as options. merge-tree handles all your normal query keys, merge-ident handles merging in any keys that are idents.

There are default implementations for both, but they are not really appropriate for datascript... just appropriate for using the default atom.

So you over-ride them with your own.

https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1612-L1620

Those are the two default functions.

@bplatz: I see. So you generate "synthetic" keys in the local application data while loading from a remote source?

Yes, exactly.

And in fact I sometimes do it at the remote... I'll just add the keys to the response. Depends on if I think it really is a client-specific thing.

Most of the times on the client though.

FWIW, here is my merge-tree

`(defn merge-tree [db data] (doseq [[k v] data] (merge-data db k v)) @db/conn)`

Then my merge-data is a multifunction dispatched off k

@bplatz: Thanks, will investigate.

And FWIW, my merge-ident

Are there any more examples of using datascript with om next?

https://github.com/omcljs/om/wiki/DataScript-Integration-Tutorial I have looked at that and it seems like a good starting point, but I would just like to see a few more examples to wrap my head around how it all looks in a slightly larger demo

@bplatz @stuartsierra I’m contemplating this exact same thing regarding synthetic keys, thanks for the discussion!

Anyone have any example of passing a query to the cb function that's passed to the reconciler send function? Not sure what it's supposed to do. Say if I have app-state {:foo {:bar 42 :baz 23}} and my reconciler send wants to update :baz, would (cb {:baz 99} [:foo]) be a correct call?