Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update loop syntax for arrays and objects, deprecate $index and $key #3073

Closed
chrisvfritz opened this issue Jun 13, 2016 · 4 comments
Closed

Update loop syntax for arrays and objects, deprecate $index and $key #3073

chrisvfritz opened this issue Jun 13, 2016 · 4 comments
Assignees
@yyx990803

Comments

@chrisvfritz
Copy link
Contributor

Deprecating $index and $key

Both of these are being deprecated in favor of more explicit named indices and keys. This syntax is a bit magical and has limitations in nested loops. As a bonus, there will be two fewer points of syntax for newcomers to learn.

New array syntax

  • value in arr
  • (value, index) in arr (switched order of arguments to be more consistent with JavaScript's forEach and map)

New object syntax

  • value in obj
  • (value, key) in obj (switched order of arguments, partly to be more consistent with many common object iterators, such as lodash's)
  • (value, key, index) in obj (index will now be available in object iteration for visual purposes, such as table striping)
yyx990803 added a commit that referenced this issue Jun 13, 2016
@yyx990803
implement new v-for iterator syntax (ref: #3073)
cec833a
@simplesmiler
Copy link
Member

How would this be supported in 2.0-migration?

@yyx990803
Copy link
Member

@simplesmiler as of now I don't think it's feasible to provide a "seamless" migration build like the 0.12 to 1.0 upgrade, due to how much underlying implementations have changed. The deprecation warnings will mostly be used for features that can be simulated.

@prog-rajkamal
Copy link

prog-rajkamal commented Jun 15, 2016 •
edited

@yyx990803
I believe this can be simulated in 2.0-migration by adding an optional parameter oldArgsOrder which defaults to true in 2.0-migration build and false in 2.0 build.

This is how it will work:

  • 2.0-migration build, using 1.0 syntax will give warnings to switch order and use oldArgsOrder = false, default is true in this build.
  • In 2.0 build, using oldArgsOrder parameter will encourage new syntax as default and mark this feature as deprecated for 3.0+

It certainly does not look like elegant but I prefer it over no seamless-migration build.

I don't what other problems which you are facing. But I am certain that seamless migration is possible with some workarounds which many will find acceptable.

@yyx990803
Copy link
Member

@prog-rajkamal hmm, that's a good idea. Toggle between incompatible interfaces using flags would definitely make a migration build more feasible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@yyx990803 yyx990803

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@yyx990803 @simplesmiler @chrisvfritz @prog-rajkamal