FormData.prototype.get should return `undefined` for not-present entries, instead of `null` about xhr HOT 10 CLOSED

Whatever we do here should also be applied to URLSearchParams and Headers.

from xhr.

Having said that, most platform APIs today return null for not-present cases, e.g., getElementById() or getAttribute(). And types here are constrained whereas they are not with Map and Set.

from xhr.

Yeah, I agree with all that. I think it would be better to be consistent though since this is so clearly parallel to a Map. E.g. I can easily see myself or another developer writing code like const thingy = formData.get("key"); if (thingy !== undefined) { ... } based on their experiences with Maps.

from xhr.

Is there a reason why TC39 went with a return value of undefined? Any chance of getting them to change it?

from xhr.

undefined is definitely appropriate in ES semantics. It's what is always used in ES for missing values, e.g. try anyObject.aaidfjhosdfijdfjdof and you'll get undefined. No way that's changing.

from xhr.

This cannot really be fixed until whatwg/webidl#60 is fixed. And at that point I guess it depends largely on willingness of those implementing since this changes a bunch of APIs that have already been deployed.

from xhr.

@domenic is this still something you think we should pursue? Nobody has really moved the IDL issue along and I'm doubtful that implementers want to make a potentially breaking change here.

from xhr.

I still think it's worth fixing, without waiting for IDL (just use "any" like many other APIs that need to return undefined are doing). I don't know about implementer willingness to change though.

from xhr.

Fair, if anyone is interested in trying to make this happen, let me know. I'm not going to actively pursue this myself.

from xhr.

Given lack of interest and how risky this is, I'm closing this. Sorry.

from xhr.