Why not design it so that the imported content can be directly accessed in the vue template?

[alamhubb]

<template>
{{testVal}}  //undefined
</tempalte>

import { testVal } from './testValue.js'

export default {

}

Why not allow direct access to the imported data in the template? What are the considerations for this design? It feels so troublesome. It would be simpler if it could be accessed directly.

[LinusBorg]

Technical reasons, mostly. Let's look at an example:

<script>
import uuid from 'some-uuid.-package'
export default {
  data: () => ({ 
   uuid: myUuid() 
  })
}
</script>
<template>
  <div>{{ myUuid }}</div>
</template>

The compiler transfers the template into a render function similar to this:

render: (_props, ctx) => {
  return h('div', ctx.myUuid) 
}

That is to say: all "variables" accessed in the template are rewritten to the format of ctx[variable]. While we have a static whitelist for a few globals like Math, the compiler can't dynamically infer the names of global variables in the module scope, i.e. from imports.

The situation is a bit different when using <script setup>, because here, the whole script block is also compiled and can perovide dynamic context to the template compiler. We can't do the same for options API, really, because Options API code has to work without a build-time compile step in the browser, where we can't ship a JS parser&code generator for size reasons.

Also, in <script setup>, there is no risk of ambiguity. Looking again at a variation of the example:

<script>
import uuid from 'some-uuid.-package'
export default {
  data: () => ({ 
   uuid: uuid() 
  })
}
</script>
<template>
  <!-- should this refer to the data property or the global package? -->
  <div>{{ uuid }}</div>
</template>

that ambiguity doe not exist in <script setup>:

<script setup>
import uuid from 'some-uuid.-package'
// this code will immediatly throw an error because `uuid` is already defined
const uuid = ref(uuid())
</script>
<template>
  <!-- So there can't be any ambiguity here -->
  <div>{{ uuid }}</div>
</template>

[alamhubb]

Thank you for your professional and attentive answer. Ambiguity problems are relatively easy to resolve. You can first use variables in the "this" field. Java will do this or can require that there are no duplicate names.

I will only be using the options api in nodejs, not in the browser, so will this meet my needs?

Can you give me some ideas if I want to do this? Does this mean I need to precompile the code and then add the imported code into ctx ? Can I complete this function in the form of a vue plug-in without modifying the vue source code?

Looking forward to your reply

[LinusBorg]

Ambiguity problems are relatively easy to resolve. You can first use variables in the "this" field. Java will do this or can require that there are no duplicate names.

I can't quite follow here.

I will only be using the options api in nodejs, not in the browser, so will this meet my needs?

Can you give me some ideas if I want to do this? Does this mean I need to precompile the code and then add the imported code into ctx ? Can I complete this function in the form of a vue plug-in without modifying the vue source code?

Something like this might be possible, but it seems overkill to me just to avoid a bit of code:

import uuid from 'uuid'
export default {
  created() {
    this.uuid = uuid  // now will be available in the template.
  }
}

if you would want to write a vite plugin that runs over .vue files before the normal compiler, you would have to modify the code to implement something like the above snippet to make it work. I don't think you would be able to hook into the template compiler in a suitable way, so you would have to modify the script part instead.

Or just use script setup.

[alamhubb]

Thank you very much