model set enumerable

[sacesare]

Hi, I've some model:

m1= {
   id: true,
   p1: '',
   p2: [ m2]
....

}
m2= {
   id: true,
   p2_1: ''
     ...
}

I want to change instance (in "draft" mode/cache= in memory), instance has some non empty array of models m2 in p2 property. That's important, because if p2 is empty array from begining, you can set property p2 to array of models m2 without problem:

store.set( m1_instance, { p2: [....]} )

but that's not work- empty array assigned.
But if I do:

store.set( m1_instance, { p2: []} )

and after that repeat same assignment:

store.set( m1_instance, { p2: [....]} );
or even
store.sync( m1_instance, { p2: [....]} );

all work as expected.
Why I can't assign m2 model's array directly without intermediate step?

Thanks.

[smalluban]

It looks like everything works as expected. Please take a look at the PR.

[sacesare]

Sorry, but expected by whom? As I can understand, single invocation for "m1_instance" in draft mode(in memory):

store.sync( m1_instance, { p2: [....]} );
// or 
store.set( m1_instance, { p2: [....]} );

must set "p2" property to to provided array, but it does not happen.

Instead, I must take additional step, setting p2 to empty array before. By the way, store.clear(m1_instance.p2) will not work too, only

await store.set( m1_instance, { p2: []} );
// and only after that
store.sync( m1_instance, { p2: [....]} );

that's strange behavior by itself IMHO.
Scenario is simple. I must have means to reset array of models for "p2" property independent from base model, that's all.
It's array of separate defined model after all.

[smalluban]

The test performs a single set action on the draft model. As a result, the draft model array property contains the provided nested model.

Please provide the PR with a failing test.

[sacesare]

That's not related to model per se, but with same store(and same model) used by interconnected components.
For example, I've following structure:

c-form
  c-table
    c-row

all three reference same store(m) where m contains els(enumerable property in m) which displayed by c-table in rows.
Form contains some kind of "select" which change internals of model, something like html.set(), but it includes new loaded rows(els) not only selected value.
All is fine...but bad thing happens on "rerender" for "c-table" - it clean up "c-form".
"c-table" contains "c-row" which reference same(single) store property description for same single model "m"( I need to reference parent, not only item of els property).
After new value selected in c-form, I do store.sync( m_property, {select_property: e.target.value, els}), with new els loaded.
"c-table" tries to render() "c-row" deleting previous table, containing previous "c-row", which reference my single model.
And suddenly model ""resets" to default everywhere- "c-row" node removed anyway.
So, parent "c-form" becomes incorrect and lost his values, including my "selected" value.
That's real problem with component "c-row" removal(that's inevitable for rerender() or not? ) .
And if it share the same model( and same property description) with another(parent in my case) component, that parent component model property reset to "defaults" initial model state without notice.
It would be useful to not touch such singleton model, if it's referenced by other components, but don't know if possible at all in current implementation.
In short, if you add some component that reference same model(singleton) with same property descriptor(store() factory), and remove it( on rerender() of parent component, for example), but parent has reference to the same property descriptor, you reset that property for parent component to model's initial values, loosing it's state.
Parent or not, if some component disappears(removed) and it reference same single shared model by same property descriptor as other components, other components get reset.

[sacesare]

It seems there's a problem with this line clear(host[key], true),
[key] in my case is store() property descriptor shared between components with my draft model.
Default "disconnect" handler for "enumerable" ( has id:true), doesn't take into account that it's draft mode (in memory instance) or something like that.

let st= store(m)
delete st.connect;

resolved issue in my case.
Model doesn't get reset from some arbitrary component voluntary. I don't know that's include all use cases, but at least there're must be configurable option to skip "clear" behavior IMHO.
Sorry, it was not very convenient to debug issue from start, because it touch generic web component lifecycle method, which was hardcoded by lib.