https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial#building-a-simple-auto-completion-widget

a slow paced walk through of the autocompleter

should answer a lot of different questions people been asking in one big swoop

David Nolen’s auto-completion widget ^^^ ported to React Native: https://github.com/mfikes/auto-completion (demo included)

@mfikes brilliant work. A real confidence builder to see it implemented so quickly

@dnolen: re: the auto-completion example - seems a (def send-chan (chan)) is needed before the definition of reconciler.

@grav: fixed, thanks

@grav: Yes, that's what I found when putting together the React Native port. David probably didn't intend for that to be an “exercise for the reader”.

hello everybody

noob question here: I was reading the "Components, Identity & Normalization" section on the om.next wiki

and I'm a bit confused regarding normalization

isn't it a bit strange to have the RootView depend on the Person component

just to "reuse" the query?

please note I may be totally misunderstanding this part

I would have naturally expected some kind of separated query to be reused in both the RootView and the Person component

so the RootView doesn't have to depend on it

for what benefit?

real UIs largely have this static up-front relationship

reusable components are separate topic

they don’t need queries anyway

hmm ok, I not such experienced with react either, so I may be missing a lot of things

if you think UI builders like Interface Builder or markup isn’t a bad idea

then you shouldn’t have a problem that queries are built up this way

all of these things are static hard coded things

that said queries need dynamism and there’s support for that too

I was wondering, assuming I may have multiple child components both having the same "identity", which one's query I should "reuse" from a parent component

but well, I think I'll need to read more, look at more code, and get back to what you said later

there have been too many interesting things to look at recently: react, cljs, om(.next), reagent, re-frame, FRP, declarative queries...

I started to play with all of them

I found reagent easy to get started with, but quickly feeled like all my components where depending on one or more "globals" (atoms)

then looked at om.next (I didn't really get Om first time I looked at it, probably because I was a clojure noob, not yet comfortable with protocols / reify)

was hooked by the way reads/mutations were separated

and the way multimethods were used

multimethods aren’t required, just done that way because it’s easy and an OK fit

as far as your first question, identity and queries are really separate concerns

without more information, I don’t understand why you would pick one query

you would need them all

I'm probably confused because I'm trying to apply "FRP-likeish" design

trying to have a "stem" state, and derived "properties" (I think it's the right word?)

well sorry for the vague question

right I would not try to apply anything you’ve learned elsewhere to Om Next

will play more, and come back with a more concrete one

it will only cause problems

seems so

Om Next stands on it’s own, there really nothing like it even with all the ideas borrowed from elsewhere

better start by following the arrows

actually, I was trying to have multiple "pages" components, and switch between them according to some state, I was not sure what was the best way to do this, maybe a multimethod, but abstracting the RootView children to later make it depend on some child component (Person) was feeling strange

would be nice to have some example of "pages" components switching

@dnolen: do you have any pointer?

will try to clarify: let's say I want to implement an address book app, first displaying a contact list, and when I click on some contact, replacing the main content (except top nav) with the contact detail

how would one achieve this? multimethods? if/else? another way?

(please not I'm not asking for the complete solution, but some keywords/pointers may help)

@sebn I would let other people describe how they are solving this problem

I don’t have any specific pointers, suffice to say there are a lot of ways to do it

ok

@sebn there's this example https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs

@rburns: thank you very much

Is there yet any example how to do remote mutations?

@juhoteperi: probably, the om-next-demo on GitHub shows this too

Oh right, I didn't notice the default mutate with {:remote true}

I have a subcomponent event that uses transact! in a function provided by Root. By itself everything works correctly and the app re-renders.

However I also want this event to update the subcomponent's local state. But when I add update-state! only the subcomponent re-renders. How can I get everything to re-render?

@paulb it’s unclear what you want to achieve

everything you’ve described so far is how it’s supposed to work

This is for a timer component with :seconds-left in local state. When it reaches 0, it transacts which affects components above it. But it also resets its own local state :seconds-left

the problem is I cannot both transact and update local state, or transact does not re-render the way I want it to

this is just too much context

outside of what you are attempting there’s either an identifiable bug or there isn't

if you believe there is than demonstrate the issue isolated from whatever you are trying to do

ok, I just wanted to make sure I'm not missing something

so far I can’t say yes or no

not enough information

When I have a component with a identity (`[:links/by-id _id]`) is it possible for the component to access other data besides the link's properties? In this case I need the current users role.

not sure what you mean

if that information is in the linked to thing then nothing more to do

Something like this: https://gist.github.com/Deraen/be6a7d4b6bf1fc26597a

@juhoteperi: If what you are trying to do is access :user/name in multiple components then its likely that making your parser recursive is an option. Another option is to use om/shared to store something like this, although I think it should be used with caution as it gets away from part of the point of this all.

Here is a simple read method that is getting the parser via destructuring the env, and then calling it again for other elements of the query.

(defmethod read :ui/quickview
  [env key params]
  (let [{:keys [state parser query]} env
        keywords (filterv keyword? query)
        joins (filterv map? query)
        joins-value (parser env joins)
        keywords-value (pull-ui state keywords)]
    {:value (merge (first keywords-value) joins-value )}))

So a simple, perhaps naive solution to your problem would be to have a read method set up of :user/name, and when you see it in the query of other components, call the parser again with [:user/name], then merge it back into your results.

Has anyone tried out path optimization yet with datascript? I need to tackle it today/tomorrow, and my first order is to figure out if Ident is required, and then if so, how to use it with datascript.

@bplatz: Thanks, I now understand that I need to handle this in parser myself

@bplatz: have not tried it out yet with anything. An ident is required on the component. See default-ui->props

have to have an ident and a query

then it will try running that sub-query through the parser directly

if you return nil, then it goes back to doing a root query

so after doing the remote tutorial it’s clearer exactly where we need error handling

https://github.com/omcljs/om/issues/486

feedback on this issue thread welcome

will try to get this tackled this week along with touch! and the mutation results issue.

@dnolen This is an isolated example of what I was talking about. sorry it's long, important part is at line 30 https://gist.github.com/prbroadfoot/b8801772d2a41409ef86 There is probably a mistake in my reasoning about how re-rendering works, I am still pretty new at React

It appears I am no longer able to invoke a transaction using the reconciler as the first argument: Assert failed: transact! invoked by component that does not implement IQuery

I used this in my router, as I had goog.events to listen to goog.history for route changes, and invoke a transaction 'out of band' of the app itself.

Is that intended behavior? I suppose I could set up the route listener inside my root component if so... but want to make sure.

This is how I call transact!: (om/transact! reconciler `[(r/route-change {:route-map ~route-map}) :r/router :r/route])

Sorry.... my error.

FWIW, the routes hadn't loaded yet and I had no reconciler object present.... need to be careful that loading of stuff is in proper order.

@paulb: will have to take a look tomorrow if somebody doesn't get to it first. Thanks for smaller example.

@bplatz: sounds like we're missing a precondition

ok, thanks

@paulb line 57: {:reset-message-fn #(om/transact! this '[(reset-message) :message])}

you need to re-read what was mutated

in this case, :message

@dnolen: The new recursive AST stuff seems to break process-roots. I’m trying to track down the problem.

Ooops. ok. It was the query-root rename. However, process-roots does seem to be broken when there is no root again. I’ll produce sample cases in your bugs devcard.