Skip to content
loading...

Hands-on Vue.js for Beginners (Part 5)

Marina Mosti on February 22, 2019

This time around we're going to look (finally) at components! So get some ☕️ and let's get started. Here's the clean slate for today's article 😁 ... [Read Full]
markdown guide
 

Hi Marina,
First a big thank you for this blog that I follow with great interest every week.
Could you elaborate a little bit on the change of prop in component?
Because the anti-pattern link that you give explains why it is a bad idea (and actually now forbidden) to change the value of the property itself in the component, it doesn't really speak about changing attributes of the property.
Which is what we would have done here by doing gameData.rating++ instead of game.rating++. We wouldn't have changed the property completely by doing gameData = {...}
?

 

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...

 

Hey I am loving this series so far! I have always wanted to get in Vue and have learned so much already with these weekly tutorial ❤️

Btw in the last code block I think there is a mistake:
game: {...this.gameData}
shouldn't it be game: {...this.game-data}, ?
Or did I miss some part 🤔 I think the error happened because at some point you switched from gameData to game-data .

 

Hi Glenn! Thanks so much for your comment :)

You are absolutely right! Somehow when I copied over the whole result I forgot to update that on the examples above. Nice catch! Also, thanks for letting me know :)

 

Hi Marina. I can only join the praise you get for this tutorial. It is one of the best I've read in a long time. Thanks!

Two comments on the code example in this section:

I was slightly confused until I discovered the implicit conversion from camelcase to kebabcase and thus did not understand that 'gameData' in the component declaration corresponds to :game-data in the game-card tag.

Also, the game variable name is used in different contexts. Initially I thought it had to be the same in both the v-for loop and the component declaration, but after toying with the source code it became clear that game in data() is unrelated to the game looping index in v-for. (Pretty obvious in hindsight)

Both these things might be part of the folk-wisdom, but for a newbie like me it threw me off the track for 15 minutes.

Again, thanks for a great tutorial!

 

Roy, thanks for your kind words :) Nice catch! It's sometimes hard to look at all the angles where someone can trip on, but your input is super valuable. Hopefully, it also helps more people that got tripped up by the same thing

 

Thanks for this lesson.

When you increase the rating, it increases the copy (not the rating in games). So when I open another browser, I don't see the rating changes that the first browser made.

How do I change the rating in games?

 

Hey Eric! Well, the status of your component is not going to persist through browsers unless you're storing it somehow on a server and then authenticating a user, this is way beyond the scope of these tutorials.

In order to change the parent's data you need to communicate to the parent of the component that the child's data has changed. You can accomplish this with either events or vuex (or some sort of state management).

I will eventually get to this in the tutorials, but if you want to try to skip ahead take a look at the docs and read about $emit and how to fire an event from your child component. You will also need to use a watched property as well, so this is kind of advanced in regard to what we have covered

 

Hi Marina,

Kudos to you for this super simple and insightful blog...
I came across this when i was searching for something in Vue.js and this really intrigued my quest to learn more about Vue !! :)

 

Hey Jyotik09, thanks for your comment :) I'm really glad you liked it! Vue is a really fun framework to work with

 

Nice tutorial. Got a little bit confused with game-data and gameData. Eventually got used to it. Great Work!

 

Interesting how Vue keeps the reactivity intact but with added costs and concepts with components. The semantics changed from data: {} to data(){return copy{}}.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Ok, please help me understand, why would anyone who's ever really worked with react ever even care about Vue?

 

Hey! So even though I frankly feel the wording of your question is a tad aggressive, here’s my personal opinion on the subject (since you’ve bothered to actually log in and actually post this I will assume you care at some extent to actually see what I have to say).

React is a great framework, with a huge amazing community behind it. I’ve used it on several projects myself, and have enjoyed using it and learning it - however it’s just not my flavour of ice-cream. As much as I love JavaScript, I don’t want EVERYTHING to become it. HTML does it’s job and it does it well, CSS (as polemic and debated as it is) does it’s job.

I would always recommend to everyone trying to learn frameworks for JS to either learn them all (if time permits, if job permits, if life permits), or at the very least to savour them to the possible extent of actually making a personal opinion that is not based on biased opinion.

Vue for me is a fun to use, accessible framework that actually makes me enjoy every project from A through Z to the fullest. The documentation is exquisitely good (shoutout the docs team!), and overall does not lack any features.

I love its clear syntax and organization, the CLI, and the smooth, accessible learning curve - yes, the learning curve. Not everyone out there is a senior FE dev with 10+ years of experience :)

Last and not least, the amazing community that has being created surrounding Vue, and all the fantastic people willing to help out, share and teach others without any form of retribution than the mere love of it. (Not that React doesn't have one!)

In the end, and to quote the wise words of a certain oracle. “I don’t expect you to do anything. I expect what I’ve always expected, for you to make up your own damn mind. Believe me or don’t.”

:)

 

As a moderator, i would say we want to keep this place hostility free and framework agnostic. This isn't a place to point fingers and say X is better than Y. If you're not interested and you're happily working with react be merry and carry on without badgering other people. Dev is a place for constructive discussion, not for framework sectarism.

 

It's not low quality, I asked a question. Can I not ask someone to explain to me why I want Vue if I'm already using React, which a lot of people think is great. Opening up to a new framework is a big investment and I felt like additional convincing was in order. You might ask yourself, if not questions about understanding, then what are these comments achieving? I understand your job as moderator is difficult and that such a question could seem inflammatory, but how could I better ask why Vue is important in the context of having had substantially positive experiences with another framework? (React in this case.)

 

Years of React experience, but my choice for all new projects Vue.

Vue ecosystem is proper one which reminds me about Ruby on Rails, where everything declared and described so well.

What are problems I can't live with in React:

  • Ecosystem maintains and lead by different people. For example Vue are responsible also for the router, state management, CLI libraries.

Oh actually it seems all next problems comes from that point. Because of this:

  • In React there no comprehensive documentation and rules which are defined by author and which covers all aspects of complex app development.As a result even onboarding new people to the team takes longer, everyone has their own opinion and experience. I don't want to have these discussions - I like develop products.

Vue built a great ecosystem with so great quality I have not seen in any other JS based frameworks before.

 
code of conduct - report abuse