Clojurians Log v2

Hi, I just finished first-mutation video tutorial. I have a question. I still don't understand why on method m/mutate 'app/add-item, we have to manually integrate ident. For example calling (uc/integrate-ident! state iatem-ident :append list-path). But on MyList don't, for example only calling (uc/initial-state Item {:label "A"}) and ident already there.

@codxse Take my explanation with a grain of salt. InitialAppState is meant to get an initial structure for the data, and establish the tables. So things declared in InitialState get normalized automatically at app start-up.

this doesn't happen at every mutation (not automatically)

@urbank do you mean when we call (om/factory MyItem) ?

@codxse Hm... I don't think so. A component doesn't need to be rendered to participate in the initial normalization. It just needs to be in InitialAppState and IQuery, as well as have an Ident (I may be wrong, though, I'm quite new)

Ok, no problem. I get it 😉

@codxse Someone's probably going to come online who's better at explaining this. In the meantime, have you seen this video by Tony Kay?

https://youtu.be/mT4jJHf929Q

Ok, let me see.

@codxse Also, merge-state! described here might be useful to you (though I haven't yet used it)

http://untangled-web.github.io/untangled/guide.html#!/untangled_devguide.M30_Advanced_Mutation

great, it will be helping

@codxse when you app starts the state, it uses the query (and it's metadata) to normalize your database, during the normalization process the indexes are going to be created and the previous initial data will be converted into idents, but that only happens on the initialization, where you data is denormalized, after that you are responsible to keep it normalized, that's why you need to do that on the mutation. makes sense?

with one refinement: server responses (or any tree-based novelty with a query run through (om/merge! reconciler tree-of-data query-for-tree-of-data ) are auto-normalized.

Untangled's merge-state! is similar (but it let's you give a component for the query)

Mutations are the abstractions over generalized database (and their remote counterpart) operations...most commonly editing a few props on already normalized data, followed by optional tweaks to graph edges)

interesting, I didn't knew the normalization also happened on merge, cool stuff 🙂

cool! it make more clear to me. :))

@tony.kay When doing a df/load on a component with :ui/* keys in the query and in the entity, they should remain untouched right?

So, @adambros found a bug when loading by ident that would mess that up

but yes, that is how it should work

I am guessing you're doing that 😕

the merge story in Untangled is one of the most complicated bits of logic, actually, because of our desire to make that happen correctly in a number of cases

Yup, but it’s a problem we’ve been able to avoid. I was just wondering what it should be so if we do hit another issue with it I can investigate. Thanks!

The "should" is: 1. If you asked for it and didn't get it, it gets removed 2. If you didn't ask for it, and you already had it, it is kept 3. Since :ui/??? are not part of what you "ask the server for", they should fall into (2)

Gotcha, makes sense!

Added as issue #69 on U.C.