Marina Mosti is a full-stack web developer with over 14 years of experience in the field. She enjoys mentoring other women on JavaScript and her favorite framework, Vue.
When you change the attributes in an object or array based prop it will still trigger a re-render on the parent, the change is also untracked and will not emit an event because it's not being listened for.
Any changes to props directly are affecting two components, parent and child at the same time so the pattern of data delegation and communication is effectively broken. The parent will re-render and trigger overwrites of the data. In some cases it will "seem" like this is not a problem, but in parent/child relationships where a lot of data is being transferred or when the parent has a lot of re-rendering happening because of state changes you are going to get yourself a free headache and very little ways to debug it.
This is actually a GREAT question, but TLDR mutating props is a huge no no - data should only be flowing one way :)
"mutating props is a huge no no"
Thanks for this.
We have a huge home made AngularJS application.
One of the base component of that is a "FieldEditor" directive.
Getting 2 props: dataRow and fieldName.
The fieldEditor component allows the user to edit the corresponding field of the dataRow.
E.g. in the parent having the row "Customer" with attributes "FirsName", "LastName", "Age", you would find3 FieldEditor in the html, 1 getting Customer + the string "FirstName" to edit the first name, another one for last name and a third one for age. Note this is an overly simplified version.
I was hoping to use Vue.js as replacement for AngularJS ... Apparently not a good idea?
Marina Mosti is a full-stack web developer with over 14 years of experience in the field. She enjoys mentoring other women on JavaScript and her favorite framework, Vue.
I dont think this issue is related to the framework, but more on how you structure our components. The parent should "feed" data to the child, and the child should "tell" the parent when that data is modified through some sort of event or shared state.
Hi Marina,
Hoping you will have the time to give yet another answer...
Sorry for coming again on this topic but this is quite important for us.
Here a mini-mini codepen showing what I mean: codepen.io/frfancha/pen/gErWKG
In this pen you can edit the name (Joe) or the age (23) in any of the "field" component in the other one is updated, so "modifying" the prop properties (not the prop reference itself) seems working perfectly in Vue.js
So we can can still use our basic building block "field" component of our big application.
(PS our "field" component does much more than the code of the pen, e.g. when the field to edit is numeric it automatically provides a calculator and other such features)
Marina Mosti is a full-stack web developer with over 14 years of experience in the field. She enjoys mentoring other women on JavaScript and her favorite framework, Vue.
Hello Fred, the fact that it "works" doesn't mean that it is correct. You will run into issues eventually when the parent starts re-rendering. The correct way to handle input wrapper components is by using a value prop and $emit with an input event so you can v-model on the parent.
Hey Fred, thanks for reading :)
When you change the attributes in an object or array based prop it will still trigger a re-render on the parent, the change is also untracked and will not emit an event because it's not being listened for.
Any changes to props directly are affecting two components, parent and child at the same time so the pattern of data delegation and communication is effectively broken. The parent will re-render and trigger overwrites of the data. In some cases it will "seem" like this is not a problem, but in parent/child relationships where a lot of data is being transferred or when the parent has a lot of re-rendering happening because of state changes you are going to get yourself a free headache and very little ways to debug it.
This is actually a GREAT question, but TLDR mutating props is a huge no no - data should only be flowing one way :)
"mutating props is a huge no no"
Thanks for this.
We have a huge home made AngularJS application.
One of the base component of that is a "FieldEditor" directive.
Getting 2 props: dataRow and fieldName.
The fieldEditor component allows the user to edit the corresponding field of the dataRow.
E.g. in the parent having the row "Customer" with attributes "FirsName", "LastName", "Age", you would find3 FieldEditor in the html, 1 getting Customer + the string "FirstName" to edit the first name, another one for last name and a third one for age. Note this is an overly simplified version.
I was hoping to use Vue.js as replacement for AngularJS ... Apparently not a good idea?
I dont think this issue is related to the framework, but more on how you structure our components. The parent should "feed" data to the child, and the child should "tell" the parent when that data is modified through some sort of event or shared state.
Hi Marina,
Hoping you will have the time to give yet another answer...
Sorry for coming again on this topic but this is quite important for us.
Here a mini-mini codepen showing what I mean:
codepen.io/frfancha/pen/gErWKG
In this pen you can edit the name (Joe) or the age (23) in any of the "field" component in the other one is updated, so "modifying" the prop properties (not the prop reference itself) seems working perfectly in Vue.js
So we can can still use our basic building block "field" component of our big application.
(PS our "field" component does much more than the code of the pen, e.g. when the field to edit is numeric it automatically provides a calculator and other such features)
Hello Fred, the fact that it "works" doesn't mean that it is correct. You will run into issues eventually when the parent starts re-rendering. The correct way to handle input wrapper components is by using a value prop and $emit with an input event so you can v-model on the parent.
vuejs.org/v2/guide/components-cust...