loading...

Vue 3 just got me from interested to excited

michi profile image Michael Z Updated on ・2 min read

Vue 3 has been on my radar for a while, but a recent RFC got me from "interested" to "excited".

I am specifically talking about declaring components.

This is how you typically do it in Vue 2:

<template>
  <div>{{ hello }}</div>
</template>

<script>
export default {
  data() {
    return {
      hello: 'world'
    }
  }
}
</script>

Vue 3 (not released yet) introduces the composition API. This allows you to put the logic together rather than being spread across options.

My first reaction to this was: cool, this will be useful for complex components, but I will probably stick with the old one for cases that don't require it.

After all, this is how the above component would look like:

<template>
  <div>{{ hello }}</div>
</template>

<script>
import { ref } from 'vue'

export default {
  setup() {
    const hello = ref('world')

    return {
      hello
    }
  }
}
</script>

Now much changed for this simple component, right? In fact, it got bigger.


Now the other day, a new RFC was posted on GitHub. Using "setup", you usually don't need methods, computed, data, and life cycle hooks anymore, so setting up "script" comes with seemingly unnecessary overhead.

So this new proposal allows us to only work using the setup method directly inside <script>.

<template>
  <div>{{ hello }}</div>
</template>

<script setup>
import { ref } from 'vue'

export const hello = ref('world')
</script>

This might look a little alien, but think about it. In Vue 2, we exported an entire object using export default for the template to use. With <script setup> we export individual parts for the template to use.

With all the indentation necessary to add a little bit of state, setting up components in Vue was always a little tedious. This svelte-react-mix completely gets rid of this problem.

Now how do we register components you might ask? This also got a DX boost. Instead of importing AND registering it, the two steps were merged into one. There still seems to be some debate on all of this, but check out the RFC for more info.

RFC: https://github.com/vuejs/rfcs/pull/182

Posted on by:

Discussion

markdown guide
 

oh com'on!! why?? ☹️ why can't we have a framework that uses language keywords for what they meant for?? export for binding fields to a template? what's the semantic here? export is meant for exporting "things" from a module, is template a JS module?

Svelte is just terrible and horrible on this side, and Vue 2 was just perfect (maybe it needed to simplify some things), but in this way is getting closer to what Angular 2+ is for AngularJS: bloody mess. 😕 quite disappointed

 

Two things I'd like to point out.

  1. The new API does not deprecate the V2 options API. On top of that, you will also be able to use setup without the syntax sugar from the RFC
  2. It's still just an RFC, open for feedback and comments
 

I know but it's not what I meant, such kind of dirty tricks do not improve in any way the development consistency and conventions. And I don't get why some JS framework development deliberately ignore this from the beginning.

I know I can be a little bit dramatic, but a RFC like this should be blasted without any discussion.

 

It’s not just an RFC per day, it rather a facade from past experience. And just like React functional components, the composition API will be the standard.

 

Hey! Want to help clarify this a bit:

export for binding fields to a template? what's the semantic here? export is meant for exporting "things" from a module, is template a JS module?

  • export isn't binding fields to the template, it's creating a JS object which Vue builds into a "reactive" object when you run the build command to compile the code. This is why we include export default or module.exports when we write a single file component in Vue 2.X.
  • The <template> tag is semantic HTML for an HTML block that gets displayed to the user using Javascript.
 

So you're actually saying that I'm right, ’export’ is now a special keyword for the build task, not for the language itself. Nice.

I didn't say anything about template tag, at least that one is still complaint.

’export’ is now a special keyword for the build task

On the contrary! I'm stating that export is still being used exactly the same as in Vue 2.

The unique piece for Vue's build tools in these examples is the setup in <script setup> of the third block.

which Vue builds into a "reactive" object

This may have been unclear wording for me to use - Vue is more optimizing the use of the exported object, not necessarily modifying the exported object.

More about export


I didn't say anything about template tag, at least that one is still complaint.

My clarification of the template tag was trying to clarify this part of your question:

is template a JS module?

Which the answer is "Not exactly".

I like this example. In Vue 2 we exported an entire object using export default for the template to use. With <script setup> we export individual parts for the template to use. It's quite similar.

Yep I got the point, but what I'm actually trying to say is «export» has now another special meaning for build task, not for the language itself or for us («us» meant as «we developers that know JS only»). In order to understand what is behind the build process, we have to read docs to understand that «export» doesn't actually exports a constant, but it helps the build task to create a «special» component with your constant inside. Worst than that you have to specify a... I don't know how to call it a «hashtag»? an «annotation»? an «empty non-compliant attribute»? anyway you have to specify setup in your script tag, otherwise export loses its meaning to build task.

Can't you see the issue here?

I think there's a disconnect here, so I want to summarize the key points of what I was trying to clarify:

  • export in Vue works the same as in Vanilla JS.
  • When Vue compiles an application, it is optimizing the code - not changing the meaning of JS keywords.

Using Vue is the same as any other framework/library in that you need to adhere to the expected format.
<script setup> is a proposed acceptable shorthand format, not unlike @click or <style scoped>.

If you have specific questions, I'd love to help clarify more. Concerns about the reliability or user-friendliness of the RFC should be expressed on the RFC.

So you're just telling me that export is used by Vue like always, Vue imports constants, functions, etc... from my script and with that it builds the component? script just says - if understood correctly - imports separately, not altogether like we used to do it in Vue2. Something like that?

Sorry I can't follow the entire RFC, too big :-D

 

Now I know why I love React JS so much, Thanks!

 

What's the point of that comment, on a post about Vue.js, if it's not just being purposefully controversial?

If anything, this makes Vue.js even more similar to React's functional API, so if it's V2's API you don't like, this post should have the opposite effect.

 

From its existing user base and previous vision, it's not a selling point being similar to React.

It's a second API and the "old" one isn't going away any time soon. Everyone's free to ignore it altogether and keep working like before. It IS a major selling point.

 

Yeah I have to agree, I like how with React it doesn't feel like there is "magic" happening behind the scenes, even though there is.

I'm not bashing Vue or Vue users here, it's fine, but after working with it on a massive codebase, I can't use it. These RFCs look like they'll improve some aspects, but I still view Vue as a tool more appropriate for smaller/prototype projects.

 

Seriously? I find that interesting. I love React, but I find it’s maintainability goes down very quickly as codebase grows. Vue’s single file components force devs to think very hard about reusability and working on huge code base was a dream

 

Could you elaborate that?

 

Reminds me of Svelte. I love it.

 

The new composition API is actually more difficult to understand. Vue2 was very declarative with the options API. I’m not sure what advantages this brings? It’s not like you have to include all options...

Moreover, this seems like overkill to fix the mixin problem? Sounds like they just got hook envy....

 

This post was more to show the new syntax, not the benefits of the composition API. Hence, my example is actually really bad from that stand point. Composition API shines once you have (with options API) related logic spread across different options (data, computed, methods, mounted, destroy, etc.). Composition API let's you group this logic together. It's not going to be an all-in replacement for Vue 2's options API. I can see people continue using it.

 

I've been doing Vue since 2 came out. These proposals for 3 are borderline ridiculous. I'll be switching to React or Svelte.

 

But they are inspired by React and Svelte :/

 

Or you could just continue using Vue 2.x syntaxing? No one is forcing you....

 

Yep most of plugins, build tools, syntaxes, etc will eventually be depreciated. Also documentation and examples will be more difficult to resource if 2.0 isn’t branched into an new project.

That's dramatic. React class based components aren't gone either, a lot of things migrated to them, yet I've still to find a React dev who doesn't know about both functional and class-based.

 

right? and there are nice improvements from a performance perspective in Vue@3 compared to Vue@2

 

Sorry i simply prefer Vue 2 and how we handle the component over v3, we shall see