@tony.kay: Thanks for the info. This all makes sense. I'll tinker with the file watching this weekend.

Also, @tony.kay is API meant to be stable now or too early to say? Is backwards compatibility going to be important?

@currentoor: The API is pretty stable. We have renamed a thing or two recently, but nothing major. I do expect there to be more extension points. The i18n lein plugin needs work, the support viewer is very alpha, but the core application framework should be pretty stable.

@ethangracer, @mahinshaw: Here is a minimal app where a follow-on mutate keyword actually works - in that only the item you have changed gets re-rendered: https://github.com/chrismurrph/om-alarming/blob/master/test/misc/checkboxes.cljs - you are given gases and the ones selected are a subset - the lines you want to graph. As you select or unselect it will show you in the dev console which item/s being re-rendered. Trouble is I have found it hard to form any kind of theory as to why it is working, let alone apply some theory to a larger application. In my big application I'm now going to be doing all mutates from the Root component, just like Kanban does it. I suspect that you with the ToDoMVC app, me and the Kanban author have all had the same problem. Would be really good for someone to try to fix the ToDoMVC app. If it can't be fixed then good because we have a small example of the problem.

why are you rereading :app/customers?

Oh yeah - that was just to show that it doesn't matter what keyword you put in it has the same effect. Part of experimenting. I put customers in there as something completely unrelated.

Didn't realize it was re-reading that keyword but good that it is. Shows that even when you get re-rendering only one of the items working - shows there's no sensible theory to explain why it is working.

Well the theory is (I really have no idea what I'm talking about) I think that some diff-ing is going on - but hard to know how to make it work and not really a part of Om Next - which just always re-renders everything from the top. The only time people experience not rendering is when there are problems with normalization. (These are my working assumptions, I'm almost 100% sure these are not correct statements).

wow, I just learned from your example that you can pass collections as dom/* children. thanks

Okay great, not exactly sure what you mean thou 😛 One thing is I'm getting rid of for now and replacing them with map. I learnt from a chat recently on Reagent channel that for and into don't play that well with React. And all the other examples use map so best to follow suit...

I think that chat fell off the logs 😞

Do you use for?

for sequence comprehensions to be quite correct!

sometimes

It was by someone who used to be in the om channel making the point that using into or for stop the react id problems. And then Gadfly explained not too efficient/correct use of React. But that might be particular to Reagent. But then all the examples we are shown (iirc) use map. Hence I'm making the switch, but missed one in that code.

Hmm - just thinking about it we can probably do what we like in render methods - we are more protected than Reagent users. Reagent is actually reading the code whereas Om Next just calls the render method, that ought to be side-effect free (although print statements still work fine, unlike with mutations).

@cjmurphy: I believe what is happening there is that React is DOM diffing all of the checkboxes and is only re-rendering the one that changed. Adding :app/customers triggers React to DOM diff because it is queried for by the root component, so the entire UI tree is diffed by React for re-rendering. Not sure why that’s different, if it is, for todomvc

If you can rely on println messages from render then it is different with the todomvc. I put some in and every item was rendered per change of one. To make them the same the call to transact! would come down to the child.

.. as I'm sure you know already.

yeah not sure why that is, i’ll look into it. as for your test file, I don’t have the time to confirm it, but you could override all of your components’ shouldComponentUpdate functions to return true. Then you might see everything re-render since the re-render call is coming from root

Okay will do.

Yes you are correct. All items re-render when shouldComponentUpdate is returning true from the 'item': GraphLineSelectionCheckbox.

makes sense, so the way that om overrides shouldComponentUpdate correctly returns true only for the component instances with changed props or component local state

It would be so nice if there was a possibility to easily log that behaviour, to answer the question 'why are so many component instances being re-rendered after such and such a mutation?' I guess it doesn't matter too much that you can use any follow on key you like, as long as Om gets the specificity right the way you say (changed props or component local state). I still don't yet trust that Om does get it right. This little demo was supposed to be the minimal example showing that it doesn't 😬

So Om has a pretty cool caching story where you can have multiple remotes and use http caching based on remote type and a hash of the query. Since untangled does network plumbing for us, is there still a way to take advantage of om's caching philosophy?

This caching stuff is not something I have to have right away but it would be nice to know we can use it after we launch and want to do performance tweaks.

Which would be months from now.

@currentoor: we’re completely circumnavigating the read-remote functionality of om and (to my knowledge) everything associated with it. You can define a custom networking object though, core/new-untangled-client takes a networking object and impl.network has the UntangledNetwork protocol that we expect a custom network to implement

Ah I see, that makes sense. Thanks!

Yup! The customization piece of networking is definitely in its infancy, we built it basically to give the user the option to use something other than XhrIo, but it could be extended in other ways I’m sure

Yeah, we'll probably need a push notification system at some point.

Props to whoever wrote the datomic migration dsl. Very convenient.