I'll try to implement these live data funcs in my app

it's planned since the beginning and it kinda works in my head

I like the idea to put follow-on reads in defmutation 😄

@vinnyataide sounds interesting, but I have no idea what you mean 🙂

@tony.kay live data functionality like meteor

oh, I see, right

You using Datomic?

@vinnyataide The method I was using was this: 1. Send a subscribe from the client (as a mutation) with the graph query of interest (as a parameter). Stash the query (on the client) so that the push notifications know what it is (and still have the component metadata on the query for normalization). You could safely store this in app state, for example. 2. on the server, associate the subscription with the websocket client id 3. Run the query and push the result to the client. The client uses the stashed query to merge/normalize it. 4. On the server, use something like clojure walk to pull out all of the :db/id from the tree of data from (3). Put those in the “watch set” for that subscription 5. Add a tx log watcher to datomic. If any of those IDs appear in the tx result, repeat (3) and update the watch set in (4) Worked fine…there is obviously some polishing from there, but it was surprisingly little code.

hey all, are there any resources out there about best practices writing parsers in fulcro? some semi-complicated real world examples would be extremely helpful. I’m a little stuck in the weeds with how to proceed actually building an application using fulcro, as I can’t figure out exactly how to structure my parsers for anything beyond toy applications

@mss What exactly do yo mean by parsers in fulcro ?

for me the video tutorials really helped get a bit of a overview of how work https://fulcrologic.github.io/fulcro/docs.html

I guess my hangup is something like: given that you’re trying to compose all child components’ queries into a root query, how do you decompose the query in that root read fn in the parser and pass those query fragments down to other parsing functions that can actually service the query fragment?

like for a totally contrived example, say I have some ui components that look like the following:

(defui NavbarSettingsDropdown
  static om/IQuery
  (query [this]
    [:user/email])
  Object
  (render [this]
    (let [{:keys [user/email]} (om/props this)]
      (dom/p nil email))))

(def navbar-settings-dropdown (om/factory NavbarSettingsDropdown))

(defui NavbarSignInPrompt
  static om/IQuery
  (query [this]
    [:authentication-request/is-loading?])
  Object
  (render [this]
    (let [{:keys [authentication-request/is-loading?]} (om/props this)]
      (if is-loading?
        (dom/p nil "Loading...")
        (dom/button nil "Sign in")))))

(def navbar-sign-in-prompt (om/factory NavbarSignInPrompt))

(defui Navbar
  static om/IQuery
  (query [this]
    [:something
     {:navbar-sign-in-prompt-data (om/get-query NavbarSignInPrompt)}
     {:navbar-settings-dropdown-data (om/get-query NavbarSettingsDropdown)}])
  Object
  (render [this]
    (let [{:keys [user/authenticated? navbar-sign-in-prompt-data navbar-settings-dropdown-data]} (om/props this)]
      (if authenticated?
        (navbar-settings-dropdown navbar-settings-dropdown-data)
        (navbar-sign-in-prompt navbar-sign-in-prompt-data)))))

(def navbar (om/factory Navbar))

(defui Body
  static om/IQuery
  (query [this]
    [:something]))

(defui RootComponent
  static om/IQuery
  (query [this]
    [{:body-data (om/get-query Body)}
     {:navbar-data (om/get-query Navbar)}])
  Object
  (render [this]
    (let [{:keys [navbar-state]} (om/props this)]
      (navbar navbar-state))))

(defmulti read om/dispatch)

(defmethod read :body-data
  [env key params])

(defmethod read :navbar-data
  [env key params])

(defmethod read :navbar-sign-in-prompt-data
  [env key params])

(defmethod read :navbar-settings-dropdown-data
  [env key params])

@mss: with Fulcro you don't have reads on the client - mutations change the state and your components pick up that state.

isn’t there still the read-local option you pass to the client?

The components you have there seem like they are 'one ofs', in which case there is only one ident for each 'class', and using InitialAppState will be able to get some of the state in place.

@mss: I have never heard of read-local sorry 😜

I know with Om Next I did have to compose all the components at the root. Or to put it another way when I debugged the state and found something not there I would add that component (get-query MyComponent) in the root query. Have not needed to do that with Fulcro so far.

interesting. seems like I’m coming at this from the totally wrong mental model since I started by diving into om

So data will either come from load (also note load-action) or from InitialAppState.

Use (dump) from user namespace to make sure it is all there and normalized properly.

Then the only problem left is rendering and sometimes having to use follow on reads.

The model is the same as Om Next, just need to embrace load and InitialAppState.

yeah that seems to be what I was missing. really appreciate the help!

@mss: Just looking at my code I have a defrouter in the Root. Another thing to look at is the initial load done from :started-callback. I think that completes important areas to look at from the client perspective.