Function-based Component API (boilerplates) about rfcs HOT 8 CLOSED

I finally found an efficient way to help me to remember to include everything in the return statement. Typescript compiler can raise an error if unused local variables are present. Those are the variables which are usually missing from the return statement.

To enable the error check, just add this line to your tsconfig.json:

{
    "compilerOptions": {
        "noUnusedLocals": true
    }
}

from rfcs.

FYI, there's nothing that prevents a userland solution to this - it should be fairly straightforward to write a Babel plugin that automatically inserts a return statement with an object containing all the variables in the setup() function scope. Could be interesting to see how the trade-off plays out. However I don't think we should make that the default.

from rfcs.

Personally, I think the return statement serves as a centralized place to be explicit about what we are exposing to the template. i.e. anything you see in the template, you should be able to locate it in the return statement, and then trace its implementation details from there. This ensures you have a straightforward way to follow through code (especially when the code is not written by yourself). It also gives you control over what should or should not be exposed to the template. Implicit/automatic exposure of properties is a no-go because it lacks these benefits.

I agree having to explicitly return everything can be somewhat verbose. One way to potentially mitigate that is by grouping different features under namespaces - i.e. split a big component into a number of composition functions, each returning an object of the properties that should be exposed, and access them in the template as nested properties:

setup() {
  const featureA = useFeatureA()
  const featureB = useFeatureB()

  return {
    // no spreading here, just access them as `featureA.xxx` in the template
    featureA,
    featureB
  }
}

from rfcs.

the return statement serves as a centralized place to be explicit about what we are exposing to the template

What if you don't want to be explicit? Up to now, Vue developers never had to worry about what is exposed to the template. We have now an additional step to remember, and probably an additional point of failure. Plus, exposing unnecessary things does not break anything, but forgetting to add something to return surely does. And that happens quite often (at least to me).

I understand this might seem like a minor issue at first. However, as you start using the Function API for real on a daily bases, you realize how annoying the explicit returning becomes. It really feels like boilerplate. I am surprised that Implicit/automatic exposure was put aside so quickly.

from rfcs.

There has already been a discussion on implicitly returning from setup() here #69

from rfcs.

Thank you for that. It seems #69 was dropped. Should I conclude the team has no intentions to tackle this issue?

from rfcs.

Duplicate of #69

from rfcs.

I was wondering if that was actually going to work. Does this mean that featureA.xyz could be a method or that featureB.foobar could be a computed property?

Edit:

So now we effectively have namespacing (something not easily possible before w/ the object syntax).

from rfcs.