3 ms·

Evan, if you are reading, I would like to say that I also fell in love with Vue, but I am frustrated that my feature request ( https://github.com/vuejs/vue/issu

Evan, if you are reading, I would like to say that I also fell in love with Vue, but I am frustrated that my feature request ( https://github.com/vuejs/vue/issues/8106#issuecomment-385367128 https://github.com/vuejs/vue/issues/8106#issuecomment-385367... ) was a little too quickly shot down, without much discussion or understanding. I understand that not every proposal can be accepted, but I think that the merit of the change wasn't even considered. I specifically designed the change to change as little as possible, and have as much power as possible. I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing. (Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)

ricardobeat 8y ago
This piqued my curiosity, so I read through the issue and here is my take: you are proposing a change that implements a _second_ way of loading async components, in addition to what's already supported [1]. This is unlikely to go through. What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process. Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers. [1] https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components https://vuejs.org/v2/guide/components-dynamic-async.html#Asy...
- rhengles 8y ago
  Thank you for the reply. I hope I am not combative in this reply, I just want you to understand from my point of view. It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components. But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue. I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.

ricardobeat 8y ago

This piqued my curiosity, so I read through the issue and here is my take: you are proposing a change that implements a _second_ way of loading async components, in addition to what's already supported [1]. This is unlikely to go through. What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process. Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers. [1] https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components https://vuejs.org/v2/guide/components-dynamic-async.html#Asy...

rhengles 8y ago
Thank you for the reply. I hope I am not combative in this reply, I just want you to understand from my point of view. It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components. But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue. I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.