A really really weird one for you guys tonight - an input with no value, defaultValue has a value???

[plain smelt]

<input type="text" name="nameOtherwise" id="nameOtherwise" className="w-full" placeholder="Name of person or company" />

this is one of the strangest issues ive ever seen

[lyric dock]

It's your browser auto-filling the input based on previous submissions.

autoComplete="off" should fix it

[plain smelt]

nope - its there on a clean refresh and also after adding that flag.

also its set in the value property of the element

[lyric dock]

Throw up a reproduction repository please.

[round osprey]

if you try on another browser, do you get that behavior too?

[round osprey]

browsers update that on the element inspector

the element inspector is not just the plain HTML the server sent

[plain smelt]

same in chrome as safari

[lyric dock]

You'll have to check the raw HTML response, not in the inspector.

[round osprey]

check if the HTML response come with that value

[plain smelt]

/* @__PURE__ */ React.createElement("input", {
    type: "text",
    name: "nameOtherwise",
    id: "nameOtherwise",
    className: "w-full",
    placeholder: "Name of person or company",
    autoComplete: "off"
  })))), 

thats weird

[round osprey]

that's not the HTML

[plain smelt]

no its the source from remix.

[round osprey]

could it be you have an useEffect filling the input?

maybe from localStorage/sessionStorage

[plain smelt]

not that i can find, searched whole project and only references are this view and my prisma schema

how can i pull up the raw HTML response?

[lyric dock]

dev tools, network, click the blue icon document request

Happy to help you continue debugging, but I'm like 99.99% sure this isn't a remix issue.

[plain smelt]

isnt even in there 🙃

never had this before, over 500+ input fields across this projcet and not a single one has done this, really unusual

the only factor really when you said about usestates is an indirect one, its within an option menu. By defualt not rendered, this is the default view

[round osprey]

if it's not in the HTML then definitely something it's adding the value client-side

[plain smelt]

then changing to other...

ive just set a value={""} on that element. that doesnt have any effect on it does it? should still submit entered content

[round osprey]

if you set the prop value without using onChange it will be impossible to change the value

[daring trail]

Does that field have the same name/id as the radio buttons that are there before? React (or the browser, not sure which) may be reusing the input field between switching tabs and keeping the value

[plain smelt]

theyre both with the name/id of "existingCustomerType", rather than the input field which is of "nameOtherwise"

[daring trail]

try adding a key to the tab content that is being rendered to tell react they are definitely not the same

[plain smelt]

good point ill try that

that fixed it. ill know for next time but i cant believe ive never seen that across the hundreds of other input fields. thanks 🙂

[daring trail]

react sees something like

<div> <label /> <input {props} /> <input {props} />

and

<div> <label /> <input {props} />

and goes "yup, same enough to reuse this structure"

[plain smelt]

i see. good to know

[daring trail]

key will let react see that they are different and remount the dom nodes entirely when it changes