Remove data object declaration

[CyberAP]

Rendered

[Leokuma]

I've always found that weird too, but there's surely an explanation for that design decision.

However, the object syntax is slightly more readable than the function syntax. Maybe you could add that as a drawback? Simplicity is a big thing in Vue, especially in comparison to React.

I would prefer the object syntax behavior to match the function syntax behavior rather than the other way around.

[CyberAP]

However, the object syntax is slightly more readable than the function syntax. Maybe you could add that as a drawback? Simplicity is a big thing in Vue, especially in comparison to React.

Those are not interchangeable and do different things, that's why it's not in the drawback section. Even though I agree that it's more readable at the same time it's more confusing for beginners to distinguish between them without knowing how components actually instantiate. It would be sad to encounter an example with an object declaration, paste that into your code and get an unexpected result.

[sqal]

object declaration should no longer be valid and produce an error with an explanation that only function declaration is valid for a component. It should also contain a link to an API and migration example.

hmm.. I am confused, because it always worked that way. There is appropriate warning in dev mode if you try to define data using plain object instead of function.

https://jsfiddle.net/vp4k9ebt/

[CyberAP]

object declaration should no longer be valid and produce an error with an explanation that only function declaration is valid for a component. It should also contain a link to an API and migration example.

hmm.. I am confused, because it always worked that way. There is appropriate warning in dev mode if you try to define data using plain object instead of function.

https://jsfiddle.net/vp4k9ebt/

Good point. I missed that it works only on a root component instance. Will update RFC accordingly. Thanks.

[yyx990803]

I like this. The impact of this change is also minimized due to the root mounting API change in v3 (where you always use a root component).

^ @CyberAP I think the above should be mentioned in the RFC.

[yyx990803]

This RFC is now in final comments stage. An RFC in final comments stage means that:

The core team has reviewed the feedback and reached consensus about the general direction of the RFC and believe that this RFC is a worthwhile addition to the framework.
Final comments stage does not mean the RFC's design details are final - we may still tweak the details as we implement it and discover new technical insights or constraints. It may even be further adjusted based on user feedback after it lands in an alpha/beta release.
If no major objections with solid supporting arguments have been presented after a week, the RFC will be merged and become an active RFC.

[michaeldrotar]

I like this.. shared state is still easy to achieve and can appear more intentional now.

const shared = {
  foo: 1,
  bar: 2
};

export default {
  data() {
    return {
      localFoo: 'foo',
      shared: shared
    }
  }
};

[JosephSilber]

You might want to add that if you don't need the this context available in your data factory (which is almost always the case), using an arrow function will get you almost the same syntax as a regular object, avoiding the extra level of nesting:

export default {
  data: () => ({
    look: 'ma',
    no: 'extra',
    indentation: 'required'
  })
}

[cawa-93]

If this RFC is accepted into the Vue, it will be necessary to further describe in the documentation how the data function differs from the setup function. I think for beginners two very similar features can cause confusion and misunderstanding "Why can't it be done this way?":

data() {
    const state = reactive({
      count: 0,
      double: computed(() => state.count * 2)
    })

    function increment() {
      state.count++
    }

    return {
      state,
      increment
    }
  }

[jacekkarczmarczyk]

Not that I don't agree that some explanation could be added to the docs, but I think that "If this RFC is accepted into the Vue" is not necessary - now you can also have data() function so it can cause same confusion and misunderstanding

"Why can't it be done this way?"

Actually can't it? I guess it would work too, didn't check though

[donnysim]

I'm honestly not sure what the actual difference is comparing setup to data - they both kind of do the same thing except setup supports returning render function? I wasn't really following the updates concerning setup so would appreciate if anyone could shed some light on this.

[yyx990803]

Technical differences:

• data does not receive any arguments. setup receives a reactive props object with a context exposing intentionally minimal amount of properties.
• data has access to this while setup does not. (Exposing this in setup doesn't offer much but leads to footguns)
• data can only return objects while setup can return render functions.
• setup can be an async function (used in combination with Suspense) while data cannot.

Conceptual differences:

• data is meant for returning state only. There should be no side effects. data is a part of the Options API and is meant to be used with the rest of the Options API.

• setup is the entry point for Composition API. It allows you to pretty much express everything a component needs. You can setup watchers, register lifecycle hooks or even initiate and wait for data requests in it. Returning state is only a subset of its functionality.

[bodograumann]

@CyberAP Please update link to rendered RFC.

[lshapz]

updated link to the rendered RFC

[CyberAP]

Thanks, updated now.