@tony.kay: the parser thing is just a vestige I think, no one reason to drop processing like that anymore

On OM-503, care to discuss? Or you just want to ponder?

@tony.kay: parser thing fixed in master

thanks

feel pretty tried post turkey day

happy to chat about it early next week

oh cool...it is written down Relax

OM remotes introduce novelty via a callback function which is called with the data returned. Is the callback exactly equivalent to manually introducing novelty via (om/merge! reconciler data)?

I'm specifically wondering ... Does the callback include required context? Does the callback control when rendering occurs? Can we reuse the callback in the case that queries are done individually? (considering a SignalR remote)

this might answer my q directly. https://github.com/omcljs/om/blob/b7ad3af100a3aa1f476445e9d2766df3f6c307f7/src/main/om/next.cljs#L1306

Is merge! meant to be used in mutations?

I’m trying to add a new item to a list and keep it normalized without having to do so manually

I think you want to use transact! and a mutate fn

My plan for merge! is where the server broadcasts to client to update some data.

I was trying to use merge in the mutate function. Probably not the right thing to do. So to add an item to a normalized list would you have to update the list with the ref and add a new identity?

I was trying to figure out if there was an om-idiomatic way to do those two things together.

It'd be interesting to come up with every possible way to do that but I suggest keeping to techniques presented in the om wiki (aka swim between the flags) while you're getting a sense for what is the best solution.

That makes sense. I’ve gone through all the tutorials and couldn’t find anything on inserting into a normalized list.

ah nvm I found an example here https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces

thanks

Does anyone edit om components in vim? The indentation is a little wonky and I'm not sure how to fix it.

@tyler: inserting into a normalized list is just: insert the ident into the list, and make sure the object is in the top-level table.

and you don't want merge! in your mutation functions...merge! is for things like @olivergeorge said: merging in novelty from a side-band source like server push.

there is no automatic way to merge items into a normalized list...does the new item go on the front of the list? the back? the middle? The base merge-tree function is quite naive about the whole thing and just does a non-deep top-level merge. You can plug in your own merge functions, but during a mutation you just have to make the modifications to the app state that make sense...and there are just too many possibilities to automate.

@tyler: one thing you can do is take the non-normalized state-tree looking thing, and run it through tree->db. Then you'll have the bits in the right form...but for a small case like inserting a single item that seems overkill.

yeah I tried with tree->db and eventually landed at just doing it manually

I can see why it can’t be automated intelligently, too much variation in implementation

Just looking through the autocomplete tutorial. Seems like you could factor out the core.async and the example would be simpler. Also I think the search-field should use :onChange not :onKeyUp (at least I needed it to make it work in Chrome).

(also, thanks, just had a huge "OH!" moment about query->ast.)

This might be the simplified send fn for that example

(defn search-fn [query cb]
  (let [gjsonp (Jsonp. (Uri. (str base-url query)))]
    (.send gjsonp nil (fn [[_ results]]
                        (cb {:search/results results})))))

(defn send [{:keys [search]} cb]
  (when search
    (search-fn (-> search om/query->ast :children first :params :query) cb)))

@olivergeorge: I think the core async is there to handle things like debouncing and rate limiting that would be needed in a more robust auto complete. Html5 recommends “oninput" instead of onchange/keyup etc - https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/oninput

@dnolen: the typo fix is unrelated with OM-502, which is still happening

@codonnell You probably have to add some clojure_fuzzy_indent_patterns to your vimrc

I recently switched to using spacemacs, you get to enjoy things from the emacs world like cider without learning new key bindings

Helm was really nice (autocomplete/selection narrowing), I don't like having to learn and remember a lot of things

@danielstockton: Thanks. I tried that and wasn't able to get it to work quite right. And ironically, I discovered spacemacs last night after asking the question. It looks really awesome! I'm excited to explore it.

@codonnell: @danielstockton: Adding query and ident (in addition to render and other old methods) to lispwords should help: autocmd FileType clojure setlocal lispwords+=query,ident

@juhoteperi: The biggest problem for me is actually the indentation of the dom functions. I often wanted to put (dom/div nil on the first line and more code on the line below. Instead of indenting 2 spaces, vim would line me up with nil.

@codonnell: You can add div and other dom elements to lispwords also. I have not done it myself as I use Sablono instead of om.dom.

just spent 15 minutes trying to find an identity bug when it turned out i confused om.next/query with om.next/get-query. how about renaming the second one to bound-query?

@juhoteperi If I add elements individually to fuzzy_indent_patterns, it seems to work. I really wanted to add the whole om.dom namespace, but I think it is pattern matching on just the function name, rather than the entire dom/div expression. For now I'll give spacemacs a try, and if I don't like it I'll just functions individually.

@codonnell: Yes it only mathes against function name. It's better to use lispwords instead of fuzzy_indent_patterns when you don't need regex, it's faster to match against lispwords than against patterns.

@juhoteperi: I'll do that, then. Thanks!

is there a recommended pattern for keeping a pointer to the 'selected item' in the data tree? i've got {:sections [[:section/by-id :home] [:section/by-id :contact]]} and want to be able to render and mutate the 'currently shown' section

@sander Did you look at https://github.com/omcljs/om/wiki/Thinking-With-Links%21 - maybe close to the recommended pattern?

thanks @griffio, read it indeed and was thinking about using that, but not sure still how

probably would have a (defui CurrentSection …) that queries for '[:current-section _], but then i'm not sure how to add joins/unions to that query

@sander: Having {:current-section [:section-by/id :home]} in your app state would make sense. Then, query the usual way - [... {:current-section (om/get-query CurrentSection)} - and you should be set.

@jannis: cool, that's what i was hoping for and trying, it just seems that [{:current-section (om/get-query CurrentSection)}] expects the resulting :current-section val to be a vector (since the query contains a join)

You'll need a read function that resolves the link in :current-section into the real thing, e.g. by doing something like {:value (let [st @state] (get-in st (get st :current-section)))}. (get st :current-section) retrieves the link, (get-in st [:section/by-id :home]) resolves it into the real thing.

@jannis: ah nice, i've been trying to keep my read-fn limited to something like (om/db->tree query (get st k) st) but it makes sense to extend it for this case, and i can still do db->tree on the results. thanks!

You don't really have to go back to the tree instead of db, you can just resolve the link in the normalized app state via get-in. That's one of the benefits of normalization after all.

And the db still has all your data, only organized differently.

@sander it’s too late for me to want to change names like get-query

@anmonteiro: thanks for the clarification

@jannis the db->tree was for references i have within sections, e.g. the :contact section refers to various [:contact-link/by-id …] values. but good points, i notice i have to think a bit more pragmatically about data. thanks for the help!

@dnolen: understood, i'll get used to just not trying to call om/query in my code

@sander: Ah, right, makes sense. Good luck

@dnolen: would you consider adding a 3-arity get-computed ([component props k-or-ks]) for the case when we want to read the next/prev-props's computed?

@anmonteiro: sure patch welcome if you’ve sent in a CA

Alright, could you pls send a CA then?

Pming my email

thanks

@dnolen: FYI, I'm writing a new process-roots...just about done.

just so we don't dupe effort

Cool!

@dnolen: process roots is done. There is one issue that we should resolve at some point soon, and it is explained in the PR text.

@tony.kay: cool will take a look later and offer feedback, thanks!