@mitchelkuijpers well, interestingly:
(def db {:root [:k 1]
:k {1 [:k 2]
2 {:x 1}}})
(om.next/db->tree [{:root [:x]}] db db)
; => {:root {:x 1}}
does seem to work.
and when I look at the algorithm it does seem to be recursive in it’s treatment of idents. I still would not do it, myself, though. Seems to convolute the database too much.
I’m confused as to why you’d need to do that
but now the question is: since Om Next supports it, should our forms support as well
In a form we have an default value which I only know when the data is loaded. Because the values are configurable
So I want so set a ident somewhere to fill the default value when it's loaded
And I noticed indeed that it works in Om
default value of what?
a field?
or an entire form
I don’t see why that case just isn’t a post-mutation that puts the data where it needs to be…not sure why an ident is involved, much less two of them
if it is a field, why not just have a post-mutation on the default load that puts it into the field iff it isn’t filled. Same with a sub-form: fill in the fields with the defaults.
Yes that is how I fixed it now
A subform for a field
But now I have to load it and put it in place in the form otherwise it would just be at that place to reference when it is loaded
@mitchelkuijpers you do have to put it in place, but I don’t understand why that would lead to ident -> ident -> value
nor why that needs to be a subform for a single field
Kind of hard to help without code