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

161–170 of 253 posts

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

#161

Post by EvanYou »

Vue team lead here.

There is a lot of FUD in this thread so we need to clarify a bit:

- This API is purely additive to 2.x and doesn't break anything.

- 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime.

- This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that users can voice their opinions. It's not like we are shipping this tomorrow.

For more details, we added a Q&A section at the top of the RFC to avoid further confusions: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...

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

#162

Post by wishinghand »

Sir_Cmpwn wrote: post #153
wishinghand wrote: post #151

Earlier quoted context omitted.

How would you get data to change reactively?

Submit a form, display updated data on the new page.

So if there's unrelated data on the page that one would want to preserve after getting more data, what are the options? Send it in as a "preservationObject" or something similar and it gets returned and re-interpolated on the new page render? LocalStore? Query Params?

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

#163

Post by Sir_Cmpwn »

wishinghand wrote: post #162
Sir_Cmpwn wrote: post #153

Earlier quoted context omitted.

Submit a form, display updated data on the new page.

So if there's unrelated data on the page that one would want to preserve after getting more data, what are the options? Send it in as a "preservationObject" or something similar and it gets returned and re-interpolated on the new page render? LocalStore? Query Params?

Don't store state on the client, store it on the server. Or use cookies.

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

#164

Post by dmix »

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.

I see, I don’t help people often with programming problems so I’ll defer to you guys.

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

#165

Post by undoware »

itwy wrote: post #92
undoware wrote: post #60

Earlier quoted context omitted.

A JS framework that a hobbyist can understand in an afternoon is frequently, but not always, not a framework that works at cloud scale. I support all the choices you make, but there are those of us who have good reason to value useful complexity. <3

JS frameworks have nothing to do with "cloud" scale.

huh that's funny I could have sworn

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

#166

Post by jcadam »

hardwaresofton wrote: post #142

Before you lament this move (and it's similarity to hooks/increase in complexity for questionable gain), check out John Lindquist's talk on Proxies: https://www.youtube.com/watch?v=95haj8RqR5o This is what Vue 3 is using -- Proxy support enables really easy and natively supported observables (as well as enabling a bunch of other crazy stuff), and it's actually pretty impressive. I think the reactivity system is Vue's…

As a "full-stack" developer I just don't have the time to follow the JS circus as closely as a dedicated front-end dev would. I switched from Backbone to Mithril a few years back (major improvement to my productivity) and I see no reason to go through the effort of learning a new framework again.

But if I had to find a new framework for some reason, I'd probably go with Vue.

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

#168

Post by hardwaresofton »

jcadam wrote: post #166
hardwaresofton wrote: post #142

Before you lament this move (and it's similarity to hooks/increase in complexity for questionable gain), check out John Lindquist's talk on Proxies: https://www.youtube.com/watch?v=95haj8RqR5o This is what Vue 3 is using -- Proxy support enables really easy and natively supported observables (as well as enabling a bunch of other crazy stuff), and it's actually pretty impressive. I think the reactivity system is Vue's…

As a "full-stack" developer I just don't have the time to follow the JS circus as closely as a dedicated front-end dev would. I switched from Backbone to Mithril a few years back (major improvement to my productivity) and I see no reason to go through the effort of learning a new framework again. But if I had to find a new framework for some reason, I'd probably go with Vue.

A very reasonable stance -- congratulations on getting lucky (unless it was the result of tons of research) and picking Mithril after jumping from Backbone (+Marionette I assume). There were a lot of wrong, but good-looking choices to make there.

In case it wasn't clear, I still think Vue is the best minimal component library all things considered -- simple syntax, simple and mostly clear usage, support for typescript, not too much overbearing tooling (they're trying to "fix" this with vue-cli though), and a large community & ecosystem. I'm just scared they're going to blow it and start putting in , but I'm well aware I'm just a hanger-on to the project (I don't contribute to it).

Mithril[0], on the other hand is almost allergic to change, in the linux kernel way, which is great until you have a problem with how it works or think it should work differently. Mithril is also the most complete though -- it has routing, AJAX, all that stuff built in (context: normally when people say "vue/react" they mean "vue/react + vue/react-router + vuex/flux"). I also particularly like how Mithril uses the hyperscript syntax and just calls it a day -- full "single file components" without the transpilation hassle. Mithril also passes one of the key indicators for high quality software, a comparisons page[1].

Shameless plug -- I wrote a short guide[2] on how to get started with mithril & parcelJS (ignore the link URL, I started with rollup and then quit because it was too inconvenient to use, I write about it in Step 5):

[0]: https://mithril.js.org/

[1]: https://mithril.js.org/framework-comparison.html

[2]: https://vadosware.io/post/mithril-systemjs-and-rollup-gettin...

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

#169

Post by vmware513 »

patorjk wrote: post #99
tnolet wrote: post #16

I might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers. I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed everything . Not against change, but the API is fine. Just iterate and evolve it. disclaimer: Big fan of Vue, early user and conference attender..

A few months ago I had to decide between Vue and React/Redux for porting over a very large Angular 1.x app at work (I decided against Angular2+ - mostly because I feel pretty burned by Angular). Seeing this headline made me very glad that I picked React. Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"

Why you didn't considered Ember.js? It is modern, great community support, opinionated and easy to use.

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

#170

Post by fourthark »

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…

So don't listen?
Post reply on HN