@tcarls to clarify, you're wondering why :query lives in the component's IQueryParams and not in an app-state atom?

@sova, correct.

So the app in question is an input field that returns a list of wikipedia entries based on what you've typed so far. Every keystroke or backspacing changes the query and the wikipedia search is re-run. If one wanted to persist what had been typed so far, an app-state atom with some sort of backend [eg datomic or whatever] would be necessary... Anything that lives in an app-state atom is only seen by a read fxn and adjusted via a mutate function (somebody knowledgeable please correct me if i'm off on this), this is kinda a short-circuit to that functionality it seems. It's like a scratch-pad for a component, and you don't need to worry about implementing read or mutate for a new keypress because it's just a #js{map} that uses :onChange to funk with the query. You could make a mutation that looked like `#js {:onClick (fn [e] (om/transact! this [(search/update-query ~props)]))} and then have a (defmethod mutate 'search/update-query [{:keys [state]} _ {:keys [query]}] {:action (fn [] (swap! ...))}) but :onChange is super convenient in this case because it's already most of the functionality we need to achieve what we want. long story short: path of least resistance

@tcarls ^ fwiw hth

thank you

@tcarls anytime. this is not exactly the same question, but may prove to be useful resource (just found it myself) https://anmonteiro.com/2016/01/om-next-query-syntax/

nod -- that happens to be one of the tabs I'm keeping open for reference. 🙂

@asultanpur not yet - I’ll get back to it eventually

Having an issue when building our project in :advanced mode: all invocations of om/get-query in our App component's query end up returning nil

@jfntn: sounds like an issue with versions. tell me if I'm wrong, but if you're on alpha47 you need CLJS 1.9.293 or higher

@anmonteiro correct we’re on alpha47 but using CLJS 1.9.293

It should work, then. Do you have something minimal I can look at?

anmonteiro not at the moment, but I’ll let you know when we investigate the issue

anmonteiro wrt to versioning, tried the latest version and the issue persists, will try to get a repro together

I have a beginner's question: if a value changes in the database, it's updated automatically in the UI, right? Or if not, how can I ensure this behavior for all connected clients? My current idea is to use sente, talk socket-jazz from a back-end to a front-end, but then that requires also watching for when the database is transacted... or perhaps the client who affects the change sockets over the fact they did so, and then the server sees that... it just seems like i'm still looking at it from a node&html+js backend/frontend lens. Anybody shed some light?

anmonteiro bit puzzled here. I copied our project.clj to a new project and added a minimal 2-components core.cljs. Worked fine, couldn’t reproduce. Then I copy/pasted the minimal core.cljs back in our app, replacing our cljsbuild :main and there it is! The compiled files are only a few bytes apart so I’m comforted in my assumption that there is nothing left of our app code in that output yet the behavior is completely different. Would appreciate any pointers!

@sova back-end database changes do not reflect automatically in connected clients ala meteor (or whatever’s in now). you will have to wire everything up yourself in om, which should be pretty straight forward- client triggers a remote mutation -> on the server’s mutation handler push a message to connected clients -> on other clients' end each received message is transacted on the app/reconciler. also check out untangled framework’s websocket cookbook recipe which gives an example of multi client group chat. https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/websockets

@jfntn: have you tried cleaning your build? I don't have any other pointers

Sounds like something specific to your app if it occurs on an empty (build) cache

@sova, you might try playing with https://github.com/metasoarous/datsync -- that's what I'm planning on trying to apply for the purpose (of syncing a selected subset of backend Datomic changes over to a client-side Datascript database). Not that it's built with any intention of integration with Om whatsoever -- it's part of the competing Datsys stack, but my evaluation thus far has been that Datview isn't ready for prime time.

@sova - we do something similar with Sente and Om at work and even though you have to roll your own, it was pretty easy to get working. The key trick for us is that Sente establishes a notion of identity for each socket (in our case user-id) and you can push to a list of identities whether or not they're actually connected - Sente figures out who is connected and therefore needs updates. My coworker wrote a post about the details: https://medium.com/adstage-engineering/realtime-apps-with-om-next-and-datomic-470be2c8204b#.cl91d4g5b

...waaaitaminute. Tracing into om.next code, on (om/set-query!), we're trying to update the state atom to have new params even when that state atom is a datascript database; we're calling (update-in st [:om.next/queries MyWidget] merge...), but "st" derefs to a datascript.db.DB, not a regular hashmap.

...hrm. My first thought was to put the DataScript DB somewhere other than the root of the state tree, but then we have a nested atom, so that won't do.

@tcarls: that's the only gotcha currently when using datascript

Dynamic queries / params have the hard requirement of an app state atom

anmonteiro, nod -- now that I'm no longer banging my head against that limitation, things are going more smoothly. Suppose I ought to submit an edit to the wiki noting it...

@tcarls: I think that's just low hanging fruit for which we never got around to create an issue

Please open one if there isn't one already

Not finding a preexisting ticket, so glad to open one.

Opened as https://github.com/omcljs/om/issues/834

Ah thank you everyone, I really admire the adstage approach... take note when the DB has a mutation and send the incremental (delta change) to the clients... so I think sente will be the way, and thanks again for all the answers.

Also, I think I learned something awesome! Bidi can be used on the front-end (cljs) and on the backend (clj) and om.next has a render to string function now (since sept? maybe earlier?) so you can have "instantaneous" (1ms gen time) responses to URLs and still have the app object loading in the background so the functionality loads in like 1-3s or whatever... has anyone used this approach ?