I'm not gonna lie, I was kinda flabbergasted when I read the RFC a few days ago. Everything I knew and loved about Vue from my 3+ years of using it was about to turn into React. Don't get me wrong, I like React too, but I like Vue better because it's NOT React.
Then I read the part of your post about extracting reusable functions and I got excited. Like you, I've written a lot of large components that I'd like to split up, but by doing so, I'd either run into using a lot of mixins (which I'm not as apposed to as others, but can definitely see how they'd get confusing, especially with global mixins) or a bunch of small components that would need to interact with each other, making the logic between them more complex.
This solves the problem fairly well, I'm just not really sold on the "grouping" aspect of this RFC and it leading to more organized code. The same can be done with React but that doesn't stop people from not doing it. Vue, as it is, imposes a structure that allows a developer to easily look at the code and understand how it all fits together. Sure, you might have to scroll up and down a few times to figure out what the data properties, computed properties and methods all are, but it's all easy to find and that's the point.
Still, with the way you can compose things from other functions with the proposed changes, I suppose this leads to being able to build smaller components, thus reducing the need for a strict structure, since there will be less going on in them. That said, I'm still definitely not 100% sold on it, yet. I think it still needs some work (ie: the .value thing is kind of confusing when you'll need to use it or not, I think that definitely needs to be hashed out better) but can be a viable option for improvement to both the current way Vue is written and in the future.
You make a couple of good points here and they are aligned with what the team is discussing internally. There are things we can do better about the current version of the function API syntax, so let's hope we reach a point in which we're fully satisfied with it.
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'm not gonna lie, I was kinda flabbergasted when I read the RFC a few days ago. Everything I knew and loved about Vue from my 3+ years of using it was about to turn into React. Don't get me wrong, I like React too, but I like Vue better because it's NOT React.
Then I read the part of your post about extracting reusable functions and I got excited. Like you, I've written a lot of large components that I'd like to split up, but by doing so, I'd either run into using a lot of mixins (which I'm not as apposed to as others, but can definitely see how they'd get confusing, especially with global mixins) or a bunch of small components that would need to interact with each other, making the logic between them more complex.
This solves the problem fairly well, I'm just not really sold on the "grouping" aspect of this RFC and it leading to more organized code. The same can be done with React but that doesn't stop people from not doing it. Vue, as it is, imposes a structure that allows a developer to easily look at the code and understand how it all fits together. Sure, you might have to scroll up and down a few times to figure out what the data properties, computed properties and methods all are, but it's all easy to find and that's the point.
Still, with the way you can compose things from other functions with the proposed changes, I suppose this leads to being able to build smaller components, thus reducing the need for a strict structure, since there will be less going on in them. That said, I'm still definitely not 100% sold on it, yet. I think it still needs some work (ie: the .value thing is kind of confusing when you'll need to use it or not, I think that definitely needs to be hashed out better) but can be a viable option for improvement to both the current way Vue is written and in the future.
You make a couple of good points here and they are aligned with what the team is discussing internally. There are things we can do better about the current version of the function API syntax, so let's hope we reach a point in which we're fully satisfied with it.