do components have to have an ident to be able to launch queries (via df/load-field)?

@curtosis: looks like yes https://github.com/untangled-web/untangled-client/blob/b1eb776d3bfff2035dcbcf521f9060a6cf30cd61/src/untangled/client/data_fetch.cljs#L36

also, it kind of makes sense right? a query needs to map to some root in the app state

hmm... yeah

I got mine working, it's weird with the tab-switching setup

I gave my mappings tab an ident of [:ui :mappings]; it doesn't have one because the tab switcher provides ident. When the data comes back, instead of being under {:mappings-tab {1 {:mappings { ... }}} (I haven't updated the tab idents to the new style yet) it naturally ends up at {:ui {:mappings {:mappings { ... }}}}.

And yes, there's an extra nesting there I'll have to sort out. 😛

I also feel like I'm doing more work than I ought to in the server read to map it to the datomic query. But for the moment it's working, so it's progress.

I think I'm still not clear on where data for a tab should be in app-state. The cookbook example uses a link, which is also very helpful, but I'm fuzzy on what happens with a regular query and what the fetch should look like.

are you referring specifically to one of the examples? I don’t think there’s any one correct way to do it

this one in particular: https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/tabbed-interface

which makes sense to load some data to a top-level key in app-state

but when I try to wire up a tab to have its local query work, things go pear-shaped

@curtosis: the example uses a link to get to some dynamically loaded data

otherwise the query is normal, and the app state is graph-natured

A post-mutation could have been used to link (via an ident) to that data in the settings object in the db...and further nested components could have been used if deeper tree structure was desired out of the data (e.g. more normalization)

The query is a union, and that part is what the example is concentrating on. The union itself doesn't affect the deeper structure

So, imagine there are no tabs (e.g. just settings). Make the recursive structure as you would in any other case. Just build the graph. If something is going wrong it has to be one of just a few things: 1. The query is wrong 2. The resulting graph in the database is wrong (e.g. post mutation didn't hook it up correctly) 3. The ident function is wrong (e.g. maybe it didn't normalize properly) 4. Your initial app state isn't composed properly Either 1, 3, or 4 will cause 2...

In general, there really isn't much to it. If the graph is right and the query is written in a way that follows it, then you should see data.

I'm not at all convinced my problem is only one of those few things. 😉

but that's a helpful way to think about what to look at.

@curtosis: The cool thing about Untangled is that those few items comprise almost everything in the "normal" application pipeline. Unless you're doing some kind of React lifecycle addition or out-of-band processing (e.g. timeout/websocket)...the only other thing I can think of is UI refresh from follow-on reads. It's just a graph database, query, and mutations. Of course, you do have to pick the data apart and pass it through the UI tree...so there are additional silly kinds of mistakes to make. But nothing else in concept since the UI render tree matches the UI query tree.

(which additionally also matches the initial UI state tree)

@tony.kay: agreed - that's why I'm using it! and the parts I do understand work superbly. 🙂

@curtosis: Remember that you can run a query on a component, and you can join on an ident. So, you could, at the REPL, hand-write a join on a specific db item's ident to a component's query. Something like: (om/db->tree { [:some :ident] (om/get-query Settings) } db db)

of course, throwing console log statements into each component to watch the data flow is another approach

@currentoor @therabidbanana @jasonjckn have any of you used untangled datomic migrations to convert existing data into a new schema format? we are trying to refactor :category/name as :tag/name. Since :tag/name already exists in our database, we can’t just rename the :category/name attribute as :tag/name. So we have to copy the data from our old categories into new tag entities. Problem is, we don’t have access to the database connection in the migrations file.

Thus far we have been avoiding this issue by saying we're in alpha - old data might be lost. 🙂

I'd love to see some good examples of how to address doing complex transactions in a migration though

yeahh we just passed that point!

ok no worries, i’ll let you know what we come up with. I imagine that we will have to pass the database connection in somehow, otherwise migrations are going to be… interesting

I could see that being useful down the road.

we found a good solution. Pretty simple. Ethan's coding it up