@jasonjckn: Hm. So, I'm not seeing nested normalization working on the older version

argh

oopps...bad query

hm...no, bad eyes

@tony.kay: need anything from me? when I tested it worked on 0.5.2 but not 0.5.3-snapshot

no...I'm just confused. I can't see it working with nested normalization at all

which makes me think I'm just not awake enough

that's odd

on 0.5.2 or otherwise

yeah

i'll try to whip up a working version

and send it

Not sure that is worth it

I'm in the midst of tracing through the guts ,so, should find it eventually

k

@jasonjckn: That should fix it. Pushed new snapshot to clojars

I really don't believe it was working right ever

but it is now

testing now

initial app state example in cookbook (on develop) pushed

shows how to do both kinds of unions

(to one and to many)

also fixes the not-found mess

wicked, works perfectly 😄

sweet

great work, thanks!

welcome. Unions are screwy, so I'm glad to have this automated helper...makes things so much better. And the initial-app-state cookbook recipe is so trivial and clear now...very nice

(even though it has both a to-one and to-many union that need initial app state)

definitely a huge improvement in local reasoning and simplicity

agreed, very happy with this

I'll probably cut a release of 0.5.3. Need to make some more docs, tutorial, and training vids on this

Done. 0.5.3 of Untangled Client on Clojars

one day i was thinking of implementing mixins for om.next like https://github.com/plumatic/om-tools but probably won't have time for a while 😉

with it you could abstract the pattern of tabs into a mixin

We got bit by https://github.com/omcljs/om/issues/604 today - wasn't sure what you guys were discussing at the time but glad I remembered there might be an om bug or could have wasted a lot of time on it.

cool, looking forward to that one being closed

In our case it's working with enums in datomic, so it doesn't really make sense to normalize those (changing {:db/ident x} to [:enum/by-ident x] doesn't seem to gain anything), but we might end up normalizing them anyway just to get it working.

@therabidbanana: you could consider using untangled.datomic.core/replace-ref-types so you don’t have to refer to enums in a nested data structure. that’s what we do for all of our enums

when I do load-field-action, the field gets replaced with an untangled loading keyword, and there's a rerender that happens, what if I just want to keep the old data around and rendered until the new data comes in ?

as oppose to rendering "loading..."

i could have two fields, one for just loading data with, and one for rendering

any way to keep just the 1 field ?

don't use load-field 🙂

use load-data with a post mutation that puts the new thing into place

@jasonjckn: ^^^^

why not load field?

load-field just builds the query for you, but if puts the marker in the app state at that spot

i see

cool

actually, not sure load-data is going to work for you either

oh.. i can try it

Untangled does the loading marker for your convenience...it doesn't need to do it; however, we don't currently have a way for you to say "don't do it"

that would be a good feature

probably should, yes

saves me from having two fields for a lot of stuff

it would be trivial to add...just put something in the load mutation that records "no loading marker"

The plumbing, when reading the ready-to-load, peppers those around in app state...it could filter out the ones marked that way

it's like 4-5 lines of new code

great 🙂

put an issue in github if you'd like, or a PR.

will do

i hooked up a spinner to :ui/loading-data on the root, so I really don't need any UIs like "loading.." throughout my entire app

since I have the spinner now whenever something is loading

yep...makes sense. have a good weekend, I'm out early.

you too

cheers

🍺

@ethangracer: thanks - I'll take a look at that - sounds relevant to our needs