-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further RFCs prior to 3.0.0 release #209
Comments
Things I noticed:
I am mostly worried about the |
Thank you for the great work. |
Thanks a lot @skirtles-code. It is indeed non-ideal for these changes to not have corresponding RFCs, but considering the typical time needed for full RFC feedback cycles, and the impact level of these changes, we don't want to block the 3.0 release for that much longer.
|
|
@jacekkarczmarczyk (5) is documented at https://v3.vuejs.org/guide/migration/props-default-this.html. Support has been added for using |
As of 3.0.0-rc.10, there are several breaking changes (relative to Vue 2) that haven't yet been through the RFC process. In several cases it has also been confirmed that an RFC will be needed.
I'm sure there are some people who will be disappointed to see new RFCs holding up the release of 3.0.0. Personally, I am more concerned about having these changes undergo proper scrutiny.
I stress that these changes are already present in the 3.0.0-rc.10 code.
I'm not trying to debate the merits of the changes here, that is what the RFCs are for. However, if anyone knows of any other changes that fall into the same category then please feel free to suggest them.
v-if
andv-for
have been flipped when using both on the same element.ref
attribute inside av-for
will no longer create an array in$refs
.flush: 'post'
). In Vue 2 they were called before rendering.default
function for props no longer has access tothis
. In particular, this prevents it from using injected properties.data
is no longer recursive. Only the top-level properties are considered.watch
option no longer supports dot-delimited paths.Perhaps you're thinking that some of the items on my list don't deserve an RFC? Maybe some don't. But be careful not to dismiss the old behaviour just because you can't think of a legitimate use-case. Giving the community an opportunity to provide use-cases is a key reason for having RFCs in the first place. Even if the decision has already been made it's necessary to gather feedback for the migration guide.
I understand that there is a lot of work involved in writing an RFC. My hope is that this list will be helpful in ensuring that nothing
gets missed as the 3.0.0 release approaches.
The text was updated successfully, but these errors were encountered: