intlify/vue-i18n

Usage of `n()` and `$n()` with `undefined` should not throw errors

MickL opened this issue · 4 comments

Clear and concise description of the problem

Sometimes values are undefined within an application, unfortunately this will throw a 500 error (at least in Nuxt) so the whole page is unavailable just because one variable is undefined:

<script setup lang="ts">
const props = defineProps<{price: number}>();
</script>

<template>
{{ $n(props.price, 'currency') }}
</template>

Another example are inputs:

<script setup lang="ts">
const price = ref(10);
</script>

<template>
<input v-model="price" type="number">
{{ $n(price, 'currency') }}
</template>

These can get undefined while the user is editing the input value which will also throw errors:

Incaught (in promise) SyntaxError: Invalid arguments (at message-compiler.mjs:77:19)

Suggested solution

It would be great if the function n() and $n() would instead just return an empty string '' without the whole page crashing or throwing any errors.

Alternative

No response

Additional context

No response

Validations

Thank you for your feedback!

The first argument of n and $n must be number.
Don't pass undefined.
It is the responsibility of the application to verify the value passed.

However, vue-i18n API documentation does not mention that an error is raised if an unexpected value is specified.
https://vue-i18n.intlify.dev/api/composition.html#composernumberformatting

I think it would help to mention it in the documentation.

Hey, thanks for your answer! It would be great if it doesnt throw an error because values can always be undefined especially when working with inputs. And because this function just returns a string it would be nice if it returns an empty string in case of undefined input imo. Currently it breaks the full page/application just because one undefined value.

Can we please allow n() and $n() to have undefined values? Consider the second example from above:

  • The first example above will break the full page
  • The second example above will throw errors because price is becoming an empty string when the input is empty

Also #1155

These strict runtime checks are incredibly inconvenient, I don't understand why you need to throw an error (often breaking the entire page) when just passing through null values and casting numbers to strings automatically would at worst display some mildly confusing strings to users and at best cause no problems because we have null checks after $t().