I'll preface this by stating I was, at first, fully on board with this RFC and excited for its release. The more I look into it though the less I like it. It seems overly verbose and hard to read at a glance due to the amount of stuff that is passed into function calls. There are brackets all over the place!
What is this RFC actually solving:
Typescript support - I think this is the main benefit of this proposal. I don't use typescript currently so I can't really provide much input on this aspect.
Modularity - This is the big one for me. I think it makes a lot of sense to abstract certain parts of a large component into smaller blocks of functionality.
Less magic? - The new syntax is arguably easier to understand for a complete novice as it doesn't require knowing that this refers to the Vue component instance and sidesteps most of the other quirks that we currently deal with.
The question is: is it really worth it? It's gonna be confusing for newcomers to learn two different methods of doing basically the same thing. It also doesn't really solve the modularity issue all that well either. Sure, it's better than what we currently have but it isn't the prettiest syntax to look at and requires a lot of boilerplate which is what we are trying to avoid in the first place right?
The main issue I have at the moment is that I have yet to see an example where I can clearly say the new syntax is better than what we currently have. Everything I've seen has just appeared like a different way of doing the same thing instead of a better way as pretty much every example is overly simple and really doesn't benefit from the new features.
In the example above it feels like the event handlers were forced in there just to demonstrate how methods in the new syntax work and add another thing to group together. If I were implementing that UI I would just base the touched state on whether the name or petSize in either case had a value. That's sorta the whole benefit of vue being data driven.
What I would prefer instead of this proposal is a way to make self contained vue objects which act somewhat like mixins but don't actually get merged into the component. Currently you can create a new vue instance and use that to modularize your code:
Ideally, there would be a way to bind this instance in such a way that lifecycle hooks are called automatically (I've used methods in my example) and vars like this.$el are bound to those of the parent component so it is a self contained object which inherits context from the component it is bound on. For me, this would solve the issue of modularity in a much cleaner way. With such a system you get the benefit of modularity without worrying about name collisions and you keep the syntax we all know (for now anyway) but it doesn't help with typescript support in any way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'll preface this by stating I was, at first, fully on board with this RFC and excited for its release. The more I look into it though the less I like it. It seems overly verbose and hard to read at a glance due to the amount of stuff that is passed into function calls. There are brackets all over the place!
What is this RFC actually solving:
thisrefers to the Vue component instance and sidesteps most of the other quirks that we currently deal with.The question is: is it really worth it? It's gonna be confusing for newcomers to learn two different methods of doing basically the same thing. It also doesn't really solve the modularity issue all that well either. Sure, it's better than what we currently have but it isn't the prettiest syntax to look at and requires a lot of boilerplate which is what we are trying to avoid in the first place right?
The main issue I have at the moment is that I have yet to see an example where I can clearly say the new syntax is better than what we currently have. Everything I've seen has just appeared like a different way of doing the same thing instead of a better way as pretty much every example is overly simple and really doesn't benefit from the new features.
In the example above it feels like the event handlers were forced in there just to demonstrate how methods in the new syntax work and add another thing to group together. If I were implementing that UI I would just base the
touchedstate on whether thenameorpetSizein either case had a value. That's sorta the whole benefit of vue being data driven.What I would prefer instead of this proposal is a way to make self contained vue objects which act somewhat like mixins but don't actually get merged into the component. Currently you can create a new vue instance and use that to modularize your code:
Ideally, there would be a way to bind this instance in such a way that lifecycle hooks are called automatically (I've used methods in my example) and vars like
this.$elare bound to those of the parent component so it is a self contained object which inherits context from the component it is bound on. For me, this would solve the issue of modularity in a much cleaner way. With such a system you get the benefit of modularity without worrying about name collisions and you keep the syntax we all know (for now anyway) but it doesn't help with typescript support in any way.