Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue RFC: Expose logic-related component options via function-based APIs instead

github.com

Post reply on HN
Print view View original

231–240 of 253 posts

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#231

Post by gustojs »

dessant wrote: post #192
karaokeyoga wrote: post #174

Earlier quoted context omitted.

I just wanted to point out a significant change made to the above document today. Earlier today, there was a "Standard" build and a "Compatibility" build. The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks. In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became…

> Compatibility That's a clue for where the Vue team's mind is regarding the current API. Compatibility to me reads like legacy. That's in contrast with the claims above that this is just a new optional API to serve a broader range of use cases.

This is a phrasing issue. In the team we use the compatibility word all the time in the "it's a good feature proposal but what about compatibility" context. For us this word had a positive conotation and we missed the fact that it can be treated in a different way. That's a good lesson for the future.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#232

Post by gustojs »

andrewprock wrote: post #225
karaokeyoga wrote: post #174

Earlier quoted context omitted.

I just wanted to point out a significant change made to the above document today. Earlier today, there was a "Standard" build and a "Compatibility" build. The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks. In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became…

The one option obviously missing is the "Production" build, which ships the 2.x API without any of the fancy new stuff that people don't want.

With Vue 3 we're introducing tree-shaking of individual Vue features which will get rid of unwanted

The "production" build will ship with the stuff that particular project uses. That means both what they use in their codebase and what Vue uses internally to handle that code.

But there also has to be a way for Vue to understand what the user wants to be in the bundle. This is easier for the users who use the new syntax, where the individual features are explicitly imported.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#233

Post by gustojs »

viraptor wrote: post #107
dmix wrote: post #69

Earlier quoted context omitted.

I don’t see how changing the name helps over a version number. This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style. It’d probably cause as much confusion as it helps.

Because it's essentially a different project at that point. All stackoverflow answers become confusing instead of helpful for example. Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.

Making it two separate project means the library authors have to write two separate libraries using two separate API - the more flexible and easier to maintain (written among others with library authors in mind) function API and the object API that they often have to fight against right now.

That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#234

Post by gustojs »

Rapzid wrote: post #72
avolcano wrote: post #9

I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone…

I really disliked the function API and felt the class API with decorators was much easier to read and work on.. I'm pretty sad they are doubling down on function API and, apparently, ditching the class API?

The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.

Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.

In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#235

Post by TehShrike »

ergo14 wrote: post #220
TehShrike wrote: post #207

Earlier quoted context omitted.

Svelte has supported compiling to custom elements for over a year.

Where are the docs for that?

See the `customElement` and `tag` compile options https://svelte.dev/docs#svelte_compile

Here are the docs from v2 https://v2.svelte.dev/guide#custom-elements

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#236

Post by ergo14 »

TehShrike wrote: post #235
ergo14 wrote: post #220

Earlier quoted context omitted.

Where are the docs for that?

See the `customElement` and `tag` compile options https://svelte.dev/docs#svelte_compile Here are the docs from v2 https://v2.svelte.dev/guide#custom-elements

Yes but svelte is on v3 - I'm asking about that.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#237

Post by pests »

pier25 wrote: post #145
pests wrote: post #134

Earlier quoted context omitted.

No rewriting needed. Hooks are just another way to do what was already possible in a more well-defined way. All the content written is still applicable. Now there is just a new way to do things too. The developers and documentation even advises against rewriting old components with hooks unless you need to.

> All the content written is still applicable. Technically yes, but what if someone only uses hooks and has never used classes? And, viceversa, since there is now a lot of people moving to hooks and producing React literature for hooks what if you only have used classes? So now, to be able to read all the React literature one has to understand both methodologies. > The developers and documentation even advises agains…

You're gonna have to learn it eventually to work with other code bases and so on. But the point was it doesn't change existing knowledge, just something new to learn.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#238

Post by jrs95 »

boubiyeah wrote: post #228
jrs95 wrote: post #137

Earlier quoted context omitted.

Restarting was honestly the best decision, they just had the wrong abstractions in AngularJS

It was! The new result just isn't all that much better. They got trapped in their own bubble of complexity.

I think it's a lot better than AngularJS 1.x was, the problem is that it isn't really better than it's competitors.

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#239

Post by tohagan »

AngeloAnolin wrote: post #81

Breaking changes such as this makes me rethink what could be the best approach with regards to front end development. I can recall the time when I moved past Angular when they introduced so many breaking change on their next version. I started using React but was not comfortable enough to keep pace with its progression. Then I found Vue which was a breath of fresh air as this framework has allowed me to deliver end p…

Meaning you didn't read the RFC which specially states:

"Is this like Python 3 / Do I have to rewrite all my code? No. The new API is 100% compatible with current syntax and purely additive. All new additions are contained within the new setup() function. 3.0 standard build will support 2.x options plus the new APIs, but you can optionally use the lean build which drops a number of options while providing a smaller and faster runtime. Details

2.x options compatibility will be kept through the entire 3.x lifecycle."

https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

Re: Vue RFC: Expose logic-related component options via function-based APIs instead

#240

Post by tohagan »

[I have no affiliation with the Vue team .. just a happy user]

IMHO, composition functions are an elegantly simple and well thought through addition to Vue brought about by a good consultative process. I think this demonstrates that Vue is in good hands with intelligent and wise counsel steering the ship. This small change is nothing like the Angular v1 => V2 experience! No one is breaking backward compatibility!!

Vue is all about coding simplicity ... and although reading through this RFC is at times heavier reading (meaning Evan's team thought through this addition very thoroughly), the final outcome is not! It's uses syntax that is very similar to existing Vue components so if you needed to refactor existing larger components into smaller composition functions, the coding experience is fast and would feel very natural and familiar with minimal to learn. No one is forcing this additional on you ... its just there if you needed it.

So please before getting spun up on any further misinformation in this thread please read the RFC from Evan You or this very thorough explanation of the RFC which has some nice coding examples.

- https://dev.to/danielelkington/vue-s-darkest-day-3fgh

Is it just React Hooks? ... here's a Comparison

- https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

My personal journey

I've coded Angular/Ionic, ExtJS & Sencha Touch, Knockout/jQuery in the past. Learning Vue was nothing like learning and keeping up with these! I was highly productive in Vue in 3 days and the learning curve and documentation was much simpler and lighter so more time to stay focused on the code. I've refactored a legacy boostrap/jQuery web site into nice Vue components in a few hours (impossible with the others!).

I'm absolutely loving the super productive Quasar Framework built on Vue 2.x/3.x which now delivers 130 components, directives and boot plugins with builders for ALL platforms: Web or SPAs (Desktop & Mobile), PWAs, SSR, SSR + PWA, Cordova iOS/Android mobile, Desktop/Electron and dream documentation.

- Check it out: https://quasar.dev

Post reply on HN