Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Max100's avatar

V-Model and null

I'm using Breeze/Vue with inertia and my forms use the Breeze <TextInput> component. If the v-model value is null, the following warning is produced:

[Vue warn]: Invalid prop: type check failed for prop "modelValue". Expected String with value "null", got Null

This occurs because the TextInput component expects to receive a string for the value of the v-model field, but the field is null.

Even so, everything works, but I want to address all warnings if possible.

One solution might be to save all null values as empty strings "" when the record is initially saved. Is that a proper solution? How do you handle this when using Breeze/Vue or the vue-starter-kit?

0 likes
7 replies
LaryAI's avatar

Great question! This is a common scenario when working with Vue components that expect a specific prop type, especially with form inputs.

Why the warning?
Your <TextInput> component (from Breeze or your own) likely has a prop definition like this:

props: {
    modelValue: {
        type: String,
        default: ''
    }
}

When you bind v-model="someField" and someField is null, Vue warns because it expects a String, not null.


Solution 1: Normalize Data Before Passing to Input

The most straightforward fix is to ensure that the value you pass to the input is always a string. You can do this in your parent component:

<TextInput v-model="form.name" :model-value="form.name ?? ''" />

Or, if using v-model, ensure form.name is initialized as an empty string:

data() {
    return {
        form: {
            name: '', // instead of null
            // other fields...
        }
    }
}

If your data comes from an API and may be null, you can normalize it when you receive it:

this.form.name = response.name ?? '';

Solution 2: Update the Component Prop Type

If you want your <TextInput> component to accept both String and null, update the prop definition:

props: {
    modelValue: {
        type: [String, null],
        default: ''
    }
}

But this is less ideal, as native inputs expect string values, and you may still get warnings elsewhere.


Solution 3: Use a Computed Property

If you can't control the initial value, use a computed property to always provide a string:

<TextInput v-model="normalizedName" />

computed: {
    normalizedName: {
        get() {
            return this.form.name ?? '';
        },
        set(value) {
            this.form.name = value;
        }
    }
}

Should you save empty strings instead of nulls?

This is a design decision. For form fields, it's common to use empty strings for "no value" in text inputs, since that's what HTML inputs provide. Using empty strings avoids type issues in the frontend and is generally safe for most backend validation.

Summary:

  • Always pass a string to <TextInput>, not null.
  • Normalize your data as early as possible (on fetch, on form init, or via computed).
  • Saving empty strings instead of nulls for text fields is a common and safe practice.

Let me know if you need a code example for your specific setup!

martinbean's avatar

@max100 Yes, you will need to coerce the value you’re passing to the input to be a String if that’s what the component is expecting.

Max100's avatar

@martinbean Not sure if it's the best way to coerce the input to be a string, but I used null coalescing ?? to set null values to '' in the useForm() function and that got rid of the warnings. Thanks for your help!

Carmila's avatar

I’ve run into the same issue using Breeze and Inertia in a Vue 3 project. Normalizing null values to empty strings right when the form initializes or right after fetching API data has worked best for me too. It keeps the warnings away and ensures your form components behave consistently.

In fact, when working on larger content-driven projects, I’ve found that addressing these small Vue warnings early helps avoid weird bugs later—especially when scaling or passing props across multiple components.

Your idea to store "" instead of null sounds like the cleanest and most future-proof approach

martinbean's avatar

@Carmila No one suggested actually storing an empty string instead of null in the database, ChatGPT.

Max100's avatar

@Carmila Thanks for your reply! I followed your suggestion and used null coalescing ?? to set any null values to '' in the useForm() function and now the warnings are gone! I also like addressing warnings for the reasons you mentioned.

I was tempted to set the nulls to '' in the db, but fixing it in the useForm() function did the trick and then I can continue to use Eloquent create() and update() functions.

Thanks again for your help!

Please or to participate in this conversation.