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.

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

Composition API (revised from #42 Function-based Component API) #78

Open
wants to merge 1 commit into
base: master
from

Conversation

@yyx990803
Copy link
Member

commented Aug 17, 2019

Rendered | Source

This is a revised version of #42.

Editorial Updates

  • Renamed the proposal to Composition API
  • Adjusted adoption strategy and position the API as an advanced, additive API that works alongside existing API
  • Reorganized flow of the document to better convey the motivation of introducing the API
  • Added separate API reference so that the RFC can focus on introducing the idea instead of technical details

Technical Updates

Even if you are familiar with the previous proposal, it is strongly recommended to read this new version in its entirety.

@ceigey

This comment has been minimized.

Copy link

commented Aug 17, 2019

Looks like a great iteration over the previous API. The explanation as to how it all works and comes together was also really good.

I did feel a tiny bit lost in the middle though, seeing so many hypothetical examples outside the normal intended usage, but that may have been simply due to the pace I was reading at or due to my mind wondering and wondering if I could... repurpose this API to somehow run lit-html with Vue's reactivity system...

Actually, that makes me wonder, for the examples where we see the API used outside of a component context, would anything work properly? Could I use reactive() and watch() in my index.js as is and have a mini-Vuex or Rxjs and implement the Meiosis pattern?

If this documentation is to be repurposed as a guide in the future (e.g. after release), perhaps a nice and short coloured "warning panel" above those code samples would be good to warn the user that the code is just for demonstration purposes.

I did notice there were already warnings but I couldn't guess their scope/severity.

@Akryum

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

@ceigey The reactivity API should work outside of Vue components.

@thecrypticace

This comment has been minimized.

Copy link

commented Aug 17, 2019

Template Refs

This makes me so incredibly happy! 🙌

The general direction of the updated proposal is excellent and much more clear. It's very well done. The addition of toRefs is also a welcome one. The names of reactive and ref are rather good as well.

@ycmjason

This comment has been minimized.

Copy link

commented Aug 17, 2019

Great stuff.

May I ask again why ref is preferable over reactive when returned from a composition function?

Also, is there anyway to set ref to become readonly?

@ycmjason

This comment has been minimized.

Copy link

commented Aug 17, 2019

Would there be an official naming guidelines for refs? E.g. prepending with Ref?

@rawrmonstar

This comment has been minimized.

Copy link

commented Aug 17, 2019

This looks really good! I wonder, besides from taking inspiration from React hooks, is there a reason the functions follow the use* naming convention? IIRC the naming convention is to remind the user that the rules of hooks apply, but it seems like Vue doesn’t have any such rules.

@liximomo

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

@ycmjason computed can be used as a readonly ref:

const readonlyWindowWidth = computed(() => window.innerWidth);
@Aaron-Pool

This comment has been minimized.

Copy link

commented Aug 17, 2019

Super well written! And, as someone who followed all the crazy ups and downs of the original RFC, I think this revision did an excellent job of addressing most of the overarching themes of that discussion 👌

@skyline0705

This comment has been minimized.

Copy link

commented Aug 17, 2019

maybe there should have a lifecycle hook called onServerPrefetch in the document……😂

@pbastowski

This comment has been minimized.

Copy link

commented Aug 17, 2019

Is there a plan to retire the V2 api in the future, perhaps in V4 or later, in favor of this new proposal?

@exodusanto

This comment has been minimized.

Copy link

commented Aug 17, 2019

vue-functional-api plugin will be updated or renamed in order to try these new features? 💪🏻

@iNerV

This comment has been minimized.

Copy link

commented Aug 17, 2019

i love this api, but i need more example with props, template refs, $listeners, $attrs, and etc. without this how i can get props or template ref inside function which outside conponent object / setup func? $listeners and $attrs wil be merged?

@afontcu

This comment has been minimized.

Copy link

commented Aug 17, 2019

vue-functional-api plugin will be updated or renamed in order to try these new features? 💪🏻

"[...] It has been made available as a 2.x plugin via the vue-function-api library. Note that the library is still reflecting a previous version of this RFC - we are working on updating it to match the latest API specs."

(source)

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

@pbastowski there's no auch Plan or desire.

@afontcu

This comment has been minimized.

Copy link

commented Aug 17, 2019

Here's some (hopefully actionable) feedback for the docs:

  • Moving from "Here double is an object that we call a 'ref'" to Ref unwrapping felt... abrupt. I was reading about a topic, and I felt like another one came up out of the blue while I was still trying to get my head around .value (<--- this is me being a bit dramatic, but still 😇)
  • The useX is used in the create folder examples, and it is suggested as a best practice afterwards, but there's no explanation or reasoning about the naming. React introduced it so that their linter rules can detect Hooks, but AFAIK this is not needed in Vue land.
  • Even though the new API "will be positioned as an advanced feature", I also feel that dropping this is a huge win for newcomers. I believe this could be stated more clearly.

Apart from that, I feel that whe way the new composition API proposal is presented is great. Kudos to the team.

@Akryum

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

useX could be a convention to make it clear it's a composition function and that it belongs in setup.

@beeplin

This comment has been minimized.

Copy link

commented Aug 17, 2019

@Akryum I sometimes also feels it awkward to name a composition function as something like “useCreateFolder”. “use” and “create” are both verbs, making it not valid English.

@Akryum

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

To me it reads like "use create folder feature".

@boonyasukd

This comment has been minimized.

Copy link

commented Aug 17, 2019

I like the new API name, since the previous name made people to mistook the API to be FP. Once they actually start using the API it should become clear to them that there's no paradigm shift to be made.

What is unclear to me now, though, is about provide/inject. From the doc, it seems that inject() always returns a ref, but the doc doesn't mention about reactive at all. Currently in my test project, I have a function that provides a deeply nested object extracted from a reactive store. So my questions are:

  • When I inject a reactive object, would that object be inside .value of a ref?
  • When I inject an object extracted from a reactive object, would it also be in .value of a ref?

If possible, I would prefer not having to unwrap reactive (or its nested object) out of a ref when using provide/inject since both of these are already reactive on their own.

@sylvainpolletvillard

This comment has been minimized.

Copy link

commented Aug 17, 2019

I am confused by the way you introduce the Ref-like container with computed and .value.

The trade-off is that in order to retrieve the latest value, we now need to access it via .value:

but then you introduce automatic ref unwrapping when used in reactive objects, which gets rid of this trade-off:

when a ref is nested as a property under a reactive object, it is also automatically unwrapped on access (...) no need to use state.double.value

So it looks like these Ref-like containers, while being unavoidable, could just be an implementation detail that users would not have to deal with directly if they are just using reactive() objects.

We have discussed whether it is possible to completely avoid the Ref concept and use only reactive objects, however:
Computed getters can return primitive types, so a Ref-like container is unavoidable.
Composition functions expecting or returning only primitive types also need to wrap the value in an object just for reactivity's sake. It's very likely that users will end up inventing their own Ref like patterns (and causing ecosystem fragmentation) if there is not a standard implementation provided by the framework.

I would like to understand why you think reactive objects could not be the standard pattern returned by composition functions. What is the usecase for a composition function that is required to only return a primitive, and not a reactive object instead ?

It is also still not clear which one between ref() and reactive() is the recommended method. reactive() is introduced first, but starting from "Code organization" section, it is not used anymore, and ref() is used everywhere instead. Why ? What is the thinking behind this ?

@dugajean

This comment has been minimized.

Copy link

commented Aug 17, 2019

I'm also facing the same confusion on when to use ref vs reactive. What's the recommended way and why?

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

@boonyasukd

  • When I inject a reactive object, would that object be inside .value of a ref?

Yes. inject always returns a ref

  • When I inject an object extracted from a reactive object, would it also be in .value of a ref?

Yes. inject always returns a ref.

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

So it looks like these Ref-like containers, while being unavoidable, could just be an implementation detail that users would not have to deal with directly if they are just using reactive() objects.

Not entirely, as the section that you quote right after demonstrates. Template refs are another example.

I would like to understand why you think reactive objects could not be the standard pattern returned by composition functions. What is the usecase for a composition function that is required to only return a primitive, and not a reactive object instead ?

Like the quote says being said, you of course can use reactive to build your own "ref", by doing this:

useDragOver(elementRef) {
  const state = reactive({ isDraggingOver: false })

  watch(() => elementRef,
    (el) => {
      // pseudocode, don't do this, won't work reliably because DnD API sucks.
      el.addEventListener('dragenter', () => state.isDraggingOver = true)
      el.addEventListener('dragleave', () => state.isDraggingOver = false)
    }
  )

  return state

But then people might want do this:

const { isDraggingOver } = useDragOver(elementRef) 

...and it won't work, the connetion to the function's internal state will be lost, and with it, the reactivity. isDraggingOver will never update.

So People have to remember do:

const { isDraggingOver } = toRefs(useDragOver(elementRef)) 

Or, you simply use a ref in the first place:

useDragOver(elementRef) {
  const isDraggingOver = ref(null)

  watch(() => elementRef,
    (el) => {
      // pseudocode, don't do this, won't work reliably because DnD API sucks.
      el.addEventListener('dragenter', () =>isDraggingOver.value = true)
      el.addEventListener('dragleave', () => isDraggingOver.value = false)
    }
  )

  return isDraggingOver

Then consumers can simply do this:

const isDraggingOver = useDragOver(elementRef)

or, as an Alternative:

useDragOver(elementRef) {
  const state = reactive({
   isDraggingOver: ref(false) 
  })

  watch(() => elementRef,
    (el) => {
      // pseudocode, don't do this, won't work reliably because DnD API sucks.
      el.addEventListener('dragenter', () => state.isDraggingOver = true)
      el.addEventListener('dragleave', () => state.isDraggingOver = false)
    }
  )

  return state

Now destructuring works as expected - but isDraggingOver is a ref.

It is also still not clear which one between ref() and reactive() is the recommended method.

Well, you kind of need both to make full use of the API, so there's no single recommended method.

that being said, we think that it makes more sense to introduce these new concepts with reactive() first as it's familiar, wherease ref() is something people have to wrap their head around first.

@smolinari

This comment has been minimized.

Copy link

commented Aug 17, 2019

I just want to say, I think this is a great "next version" of the original API RFC. The name is much better too. This new RFC shows very much the willingness of the Vue team to listen and compromise with the community, which is a golden advantage Vue has. Please keep that up!

I must admit, I too am now somewhat confused with how inject is supposed to work, especially after the comments just made here. But, I'm going to chalk my confusion up to my own lack of understanding of much more advanced JS programming and will be waiting for it to "click" at some point, as it did with the initial RFC and the whole concept of the (now called) Composition API.

Scott

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

I must admit, I too am now somewhat confused with how inject is supposed to work

  1. No matter what you pass down with provide, you will always get it wrapped in a ref from inject.
  2. Possible footgun: When you pass a primitive value to provide, it will be wrapped in a ref, but it won't be reactive (We can/will probably warn you about this in development mode). But that's the general challenge of refs to "get".
@luwanquan

This comment has been minimized.

Copy link

commented Sep 15, 2019

New feature for babel-preset-vca-jsx:
support for JSX allocation template references on render functions returned by setup().

const Hello = createComponent({
    setup() {
        const root = ref(null);
        watch(() => console.log(root.value)); // <h1>...</h1>
        /*
        return () => h('h1', {
            ref: root
        }, 'hello world!');
        */
        return () => <h1 ref={root}>hello world!</h1>
    }
});

Welcome experience.

@vmihailenco

This comment has been minimized.

Copy link

commented Sep 16, 2019

Is it possible to extend reactive to support TypeScript classes:

class Counter {
  count = 0
  double = computed(() => this.count * 2)

  increment() {
    this.count++
  }
}

export function useCounter() {
  const state = reactive(new Counter())
  return state
}

The default example does not compile with TypeScript (state gets type any since it refers itself) and requires writing a separate interface definition for the state which is unnecessary work.

@jaeming

This comment has been minimized.

Copy link

commented Sep 16, 2019

I’m late to the party on this latest adjustment but it looks much like the previous iteration except without the .value wrapper now in place.

I’ll try to explain why I feel this is going in the wrong direction (hopefully without the assumption that I’m being toxic).

  1. we already have a strong typescript story with class api syntax and class decorators. Vue cli acknowledges this and presents it as an option.
  2. the vue option-object syntax is inadequate for strongly typed vue projects.
  3. you are now proposing another 3rd syntax, another way forward, which you claim will be a low level reactivity api which is optional. However, you want this to be the official typescript story of vue, meaning that you want it to be the only way forward really.

It’s a confusing message to say the least. A lot of projects are already using the class and decorator syntax as it was the only way forward at the time. I’m currently in a 1 month old product that will have 20k plus clients and over 1 million individual users and it’s based on that syntax.
If vue cli abandons this, it will leave us on a very unsure path, just like angular.js / angular 2.

Additionally, I really don’t get the opposition to decorators and OOP in general. This setup method is just a reinvented constructor, and without the decorators we will be forced to move everything into it, which will become a procedural mess in real world apps: in other words, a real god method.

I get it, you love functional programming. But not everyone does. In fact most typescript engineers are more than okay with classes.

Even the react hooks look better than the current rfc. And btw, why are we trying to become like react? I think I vue got to where it is by being different than react.

What sets vue apart from react if we go down this path? And don’t say templates. Both angular and ember for that matter have just as good templating stories. And if I want an even more innovative and fresh templating path, I’d go svelteJS... give me some of that templating stuff like {{await}}. If I want a real alternative to react that pretends to be like react, I’ll use stencil JS.

In other words, can we please just merge the class syntax api and class based decorators to core already!? That’s what most of us already using typescript in Vue want.

@Akryum

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

it looks much like the previous iteration except without the .value wrapper now in place

The value wrapper has been necessary for ref() (previously value()) "reactive pointers" since the first iterations of the API.

meaning that you want it to be the only way forward really

That's untrue, you'll still be able to use classes with decorators. Reasons why we are not making this part of the core have already been explained many times. (Summary here)

which will become a procedural mess in real world apps: in other words, a real god method

That's also untrue, unless you really want to put all your code in a giant method 🤔️. The goal is to have small, reusable composition functions.

I get it, you love functional programming

Except it's not functional programming. That's why we changed the name to Composition API instead of Function-based API as it could be confusing.

Even the react hooks look better than the current rfc. And btw, why are we trying to become like react? I think I vue got to where it is by being different than react.

It's still very different from React.

And if I want an even more innovative and fresh templating path, I’d go svelteJS...

We believe Svelte has its own share of issues.

that pretends to be like react

We don't.

In other words, can we please just merge the class syntax api and class based decorators to core already!?

That's not going to happen.

@smolinari

This comment has been minimized.

Copy link

commented Sep 16, 2019

@jaeming - You really need to read everything there is on this RFC and read it in detail.

  1. "and without the decorators we will be forced to move everything into it, which will become a procedural mess in real world apps: a real god method."

We're talking about single file components. If your component has a huge setup() method, then you are more than likely doing the SFC wrong, even in real-world apps. In fact, this RFC will allow developers to smartly compose code so that SFC features can be grouped together and also be reused easier, making mixins obsolete (they'll still be supported though).

  1. The class and decorator path was determined as not sufficient for TypeScript support for a number of reasons and was discussed ad nauseum. The final word is here.
    https://vue-composition-api-rfc.netlify.com/#type-issues-with-class-api

  2. The class component will still be supported, albeit third party (edit: Vue supported, but as a external package). I can't find a reference to this, but all your class-based code will be fine in the future too. Maybe one of the Vue team can chime in on this?

  3. This RFC is far from React hooks and also better than React hooks.
    https://vue-composition-api-rfc.netlify.com/#comparison-with-react-hooks

And, fun fact, the React team came up with hooks because the Class API they had wasn't sufficient either. Have a watch....https://youtu.be/V-QO-KO90iQ?t=276

In other words, Vue is smartly avoiding that same path and rightly so.

Scott

Edit: Hah. @Akryum was faster..... 😁

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

As a sort of meta-reply since the content was already handled:

(hopefully without the assumption that I’m being toxic)

If you don't want your comment to be perceived as toxic, try and provide constructive criticism, ask questions that target the actual arguments that were put forth and don't present personal opinion or ignorance as fact.

Examples:

However, you want this to be the official typescript story of vue, meaning that you want it to be the only way forward really.

Assumptions presented as fact instead of a question. We clarified mutiple times that vue-class-component will be supported. If you really missed that, you could have asked about our plans instead of acting like you know what we want or plan on doing.

I really don’t get the opposition to decorators and OOP in general.

Extensive arguments were provided. Handwaving them with a "I really don't get it" isn't constructive, it makes you look either lazy or arrogant, since you don't seem willing to engage the actual arguments

Even the react hooks look better than the current rfc.

Again, a seemingly subjective "that looks better than this" doesn't make anything more clear and doesn't move the discussion anywhere.

What sets vue apart from react if we go down this path?

The class API looks a lot like angular. What sets Vue apart from angular if we use a class&decorator API? And don't say "Vue works without TS" because you are obviously a TS developer.

See how that works? Not a real compelling argument.

Aside from that:

  • progressive usecase (from <script> tag to webpack & PWA)
  • SFCs
  • official but optional extensions like routing
  • Reactivity

you may not care about all of those but claiming they, together, are not something that sets Vue apart is really handwavy, again.

In other words, can we please just merge the class syntax api and class based decorators to core already!?

Why? Because of your personal subjective preference, presented as if it were an actually constructive criticism?

I don't think so.

@OrkhanAlikhanov

This comment has been minimized.

Copy link

commented Sep 23, 2019

How will Vue 3 affect $options property? I am not able to find anything regarding it.

@nchutchind

This comment has been minimized.

Copy link

commented Sep 25, 2019

Out of curiosity, will it be possible to mix the Vue 2 component format with the Vue 3 format, or will the presence of a setup() method disable that?

For example:

<script>
const state = reactive({
  counter: 0
})
export default {
  setup() {
    
    return state
  },
  computed: {
    doubledCounter() {
      return state.counter * 2;
    }
  }
}
</script>
@sqal

This comment has been minimized.

@pikax

This comment has been minimized.

Copy link

commented Sep 27, 2019

based on the documentation for the computed

Takes a getter function and returns an immutable reactive ref object for the returned value from the getter.

Does it mean you cannot change the ref object value or you cannot change the value the ref points to?

for example:

const computedValue = computed(()=>({test:1}));
computedValue.value.test = 4; // readonly based on RFC it's not allowed
computedValue.value = ref({test: 2}); // doesn't change computed but only the ref, should this be valid?

because the typings in the docs are quite explicit:

// read-only
function computed<T>(getter: () => T): Ref<T>

should it be?

// read-only
function computed<T>(getter: () => T): ReadOnly<Ref<T>>

Note: there's already a PR open vuejs/composition-api#145 if is supposed to be readonly

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Sep 27, 2019

i should be readonly, yes - and it is at runtime. the plugin's types seem to be insuficient here.

@pikax

This comment has been minimized.

Copy link

commented Sep 27, 2019

Even when you create a computed with get and set it still be Readonly<Ref<T>>?

EDIT: Shouldn't it be:

// read-only
function computed<T>(getter: () => T): Readonly<Ref<Readonly<T>>>

// writable
function computed<T>(options: {
  get: () => T,
  set: (value: T) => void
}): Readonly<Ref<T>>
@LinusBorg

This comment has been minimized.

Copy link
Member

commented Sep 27, 2019

Even when you create a computed with get and set it still be Readonly<Ref>?

Of course not, how would that make any sense?

@pikax

This comment has been minimized.

Copy link

commented Sep 27, 2019

With get and set should be ref

The readonly get should be

// read-only
function computed<T>(getter: () => T): Readonly<Ref<Readonly<T>>>
@Jexordexan

This comment has been minimized.

Copy link

commented Sep 27, 2019

I'm getting more and more excited for this release!

I spent last weekend making a set of composition functions for autocomplete and really enjoyed the typesafety and being able to extract different concerns into different files 🎉Like, damn, it felt so good. (Still having an issue with gracefully typing props, although its getting better!)

I'm wondering if we (as a community) have put some thought into the "branding" behind new OS packages that use the composition-api.

When Vue 2 came out we saw a lot of npm install vue2-awesome-package, but that quickly became vue-awesome-package and v-awesome-package (among other, punnier alternatives) as v2 became ubiquitous. I really don't want to see vue3-awesome-package becoming a thing, as it may suffer the same dated-ness down the road.

So I'm looking at what happened with React Hooks, there are several packages that follow either the use-awesome-package or awesome-package-hooks style. These are good names, but those patterns are practically reserved for React modules.

It would be really nice to have a pattern of our own. We cannot follow React exactly, but we may be able to modify the patterns already set. Thankfully we kinda own the letter v on npm, so I'm spit-balling the following as options:

1️⃣v-use-awesome-package (my choice, atm)
2️⃣vue-use-awesome-package (longer, but slightly clearer)
3️⃣vuse-awesome-package (pun! *Portmanteau)
4️⃣awesome-package-v(ue)-hooks (but we arent calling them hooks so..)
5️⃣awesome-package-composition-functions (wayyyy too long)
6️⃣awesome-package-composition-fns (I mean, sure)
7️⃣awesome-package-composition-api (Okay, but still too long imho)
8️⃣awesome-package-composer (shorter, but unclear)
9️⃣awesome-package-vcapi (Not a huge fan)

VOTE USING 1️⃣9️⃣ REACTIONS Nevermind, apparently this isn't Slack 😞

Naming things is hard, folks

What are all your thoughts/suggestions/alternatives? What would spark joy when preceded by npm install or 'yarn add`.

Sorry if this is not quite on-topic for the RFC, but figured it could lead to a discussion among maintainers and contributors and set some good examples early on.

@leopiccionia

This comment has been minimized.

Copy link

commented Sep 27, 2019

VOTE USING 1️⃣9️⃣ REACTIONS

Is it possible to react with arbitrary emojis in GitHub?

I like 2️⃣ better. I'm not sure if Vue would require something like use* prefix for linting purposes (Vue's "rules of hooks" would be much simpler), but convention and searchability are good things, in general.

@Jexordexan

This comment has been minimized.

Copy link

commented Sep 27, 2019

Is it possible to react with arbitrary emojis in GitHub?

I thought so, but was quickly disappointed 😂

The discussion around the "appropriateness" and "usefulness" of the use* prefix has been discussed here and in other forums.

AFAIK, It is nothing but a convention appropriated for the composition api. Some are against it because it "feels like React", but I am all about code affordance. useX() this tells me as a Vue developer that I'm gonna get some reactive refs and maybe some methods when I call this function, so I better know how to use them. As @LinusBorg said in a prior comment that im not going to bother digging up, when I call useX(), I am "using the X feature." It's all about language.

@jbruni

This comment has been minimized.

Copy link

commented Sep 28, 2019

@Jexordexan - I also prefer 2️⃣

@agaluf

This comment has been minimized.

Copy link

commented Oct 2, 2019

Either 1️⃣ or 2️⃣ is fine as both vue- and v- is generally used to refer to vue packages. My vote goes to 2️⃣, as it‘s clearer.

@mgesmundo

This comment has been minimized.

Copy link

commented Oct 4, 2019

Me too 2️⃣

@desislavsd

This comment has been minimized.

Copy link

commented Oct 4, 2019

A few questions about template refs:

In the new API it seems that the ref attribute expects a path to property exposed by the setup() method.

  1. If so, can I pass more complex path like ref="refs.foo" or what would be the way to scope all my refs

  2. What happens in case of ref="foo" where foo is not exposed during setup()? Will the element be accessible via this.$refs.foo wherever this points to the component instance?

  3. Won't it be cool if in case a template ref is used along with v-for and points to a property that is a ref([]) with an empty array as an initial value to automatically behave as in the example with v-for - reset the array onBeforeUpdate and assign all the elements;

@DCzajkowski

This comment has been minimized.

Copy link

commented Oct 5, 2019

I am curious if this was raised anywhere, but what is the benefit of using the "setup" function inside an object instead of just function?

import { reactive } from '@vue/composition-api';

export default () => {
  const state = reactive({
    isDark: true,
  });

  const toggleTheme = () => (state.isDark = !state.isDark);

  return () => (
    <button vOn:click={toggleTheme}>
      {/*  */}
    </button>
  );
};

We also do not lose the type information:

import { reactive, Setup } from '@vue/composition-api';

const setup: Setup = () => {
  const state = reactive({
    isDark: true,
  });

  const toggleTheme = () => (state.isDark = !state.isDark);

  return () => (
    <button vOn:click={toggleTheme}>
      {/*  */}
    </button>
  );
};

export default setup;

Does it collide with functional components? If yes, can we mitigate it somehow?

@Almoullim

This comment has been minimized.

Copy link

commented Oct 5, 2019

@DCzajkowski I believe this is what you are talking about?
Question from luwanquan #78 (comment)
And Evan's reply #78 (comment)

@DCzajkowski

This comment has been minimized.

Copy link

commented Oct 6, 2019

@Almoullim So this means it will be supported? Awesome! Thank you for the answer!

@splincool

This comment has been minimized.

Copy link

commented Oct 7, 2019

I have read @LinusBorg presentation slides (Vue London) and it looks very complicated. Maybe he chose bad examples to introduce new features, but when @NataliaTepluhina made her presentations months ago it was so clear and understandable.
So it is still a lot of questions where the framework goes and what we will get at the end...

@LinusBorg

This comment has been minimized.

Copy link
Member

commented Oct 7, 2019

@splincool I'm sorry to hear that you found my slides hard to understand.

You should keep in mind though, that slides like these are made to go with the actual talk - not every bit of information and explanation that I talked about is in the slides. Also, this talk was the "middle" one in a series of three talks going from introduction to real world examples (mine) to live coding. In that sequence and on video they may give you a different image than looking at the slides on their own.

The Feedback that I got by participants of the concerence was positive and one of excitement rather than confusion.

Have you actually played with it already?

If you wanna talk about concerns it I'm available on discord in the evenings (european time) usually.

@smolinari

This comment has been minimized.

Copy link

commented Oct 15, 2019

FYI. Good video on the composition API for those still questioning its usefulness.

https://www.youtube.com/watch?v=6HUjDKVn0e0

Scott

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.