Skip to content

Conversation

@fusionbeam
Copy link

store commits via updateField now creates reactive properties across the nested chain.
also when dealing with dynamic properties (chains that are not known at compile time) this fix ensures the safety of the nested chain by creating store objects as needed.

the nested properties are made reactive by default according to vue recommendations (https://vuejs.org/v2/guide/reactivity.html#Declaring-Reactive-Properties)

@coveralls
Copy link

coveralls commented Feb 28, 2019

Coverage Status

Coverage remained the same at 100.0% when pulling ddb6dea on fusionbeam:master into da5fc61 on maoberlehner:master.

// console.log('BEFORE: prev[key]:', prev[key]);

if (index < array.length - 1) {
Vue.set(prev, key, prev[key] ? prev[key] : {});
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really necessary to set the value of prev[key] to prev[key] again? I guess this could affect performance in a negative way.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vue.set is the only way to ensure deep reactivity (https://vuejs.org/v2/guide/reactivity.html).

I could save Vue.set call with a direct assignment if the object property is not responsive (check the existence of a 'ob' attribute) but I think Vue.set does that anyway.


expect(store.state.form.foo1.foo11.foo2.foo3).toBe(`fooValue`);
});
});
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding an integration test, please also add / update Unit Tests to bring back coverage to 100%.

Thank you for contributing!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

@fusionbeam
Copy link
Author

think I've covered all change requests

@maoberlehner
Copy link
Owner

think I've covered all change requests

Thanks! I'll take a closer look later this week.

@fusionbeam
Copy link
Author

after further reflection i'dd like to cancel the pull request.
vue reactivity was not meant for dynamic reactive properties.

@fusionbeam fusionbeam closed this Mar 7, 2019
@loren138
Copy link

loren138 commented Apr 4, 2019

While adding whole chunks of a chain seems like it could be excessive, adding properties at the end of the chain seems useful to me.
IE user: {} and mapFields('user.name') which was the issue in #41 I think.
Looks like your PR would also handle mapFields('user.extraDetails.twitter'), which I'm not sure is entirely bad to have, but less necessary for most people.

I was thinking about pulling at least part of these changes locally into my code. Did you have reasons you thought the first use case was bad?

@ghost
Copy link

ghost commented Jan 13, 2020

@fusionbeam could you elaborate on your decision to close this pr?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants