Java developer, passionate about sci-fi lit, facial hair and a good, hot chicken broth. Totoro is my daily inspiration. You will never catch me wearing sandals.
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
Java developer, passionate about sci-fi lit, facial hair and a good, hot chicken broth. Totoro is my daily inspiration. You will never catch me wearing sandals.
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.
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.
Java developer, passionate about sci-fi lit, facial hair and a good, hot chicken broth. Totoro is my daily inspiration. You will never catch me wearing sandals.
’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.
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.
Java developer, passionate about sci-fi lit, facial hair and a good, hot chicken broth. Totoro is my daily inspiration. You will never catch me wearing sandals.
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.
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.
Java developer, passionate about sci-fi lit, facial hair and a good, hot chicken broth. Totoro is my daily inspiration. You will never catch me wearing sandals.
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
setupwithout the syntax sugar from the RFCI 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:
exportisn't binding fields to the template, it's creating a JS object which Vue builds into a "reactive" object when you run thebuildcommand to compile the code. This is why we includeexport defaultormodule.exportswhen we write a single file component in Vue 2.X.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.
On the contrary! I'm stating that
exportis still being used exactly the same as in Vue 2.The unique piece for Vue's build tools in these examples is the
setupin<script setup>of the third block.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
My clarification of the template tag was trying to clarify this part of your question:
Which the answer is "Not exactly".
I like this example. In Vue 2 we exported an entire object using
export defaultfor 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
buildtask 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 specifysetupin your script tag, otherwiseexportloses its meaning tobuildtask.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:
exportin Vue works the same as in Vanilla JS.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@clickor<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
exportis used by Vue like always, Vue imports constants, functions, etc... from myscriptand with that it builds the component?scriptjust 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