> It's already easy to see that submitter is optional.
Why force yourself to read inside function implementations like this for every function you might use when fool-proof automated assistance is right there? What if the function was tens of lines long? What if the optional value only appeared inside a chain of 5 nested functions? How would you easily fix/update your code if the value isn't optional now but got changed to be optional in the future?
Manual effort like this is error-prone, not scalable, and a huge distraction. Why would avoiding type annotations be worth this?
Maybe the types should have been written differently, to indicate that it's the type of the submitter property in a FormEvent. That's another cost of using TypeScript, is trying to get the types right. TMTOWTDI.
> Because this is an internal function in a _library_
Why does that matter? Error-prone approaches create buggy code and we don't want buggy code, whether it's a library or something else. Libraries can be huge and complex, and arguably should have more robust edge case checking than regular code.
This one: https://github.com/hotwired/turbo/pull/971/files#r1317386731
> function buildFormData(formElement: HTMLFormElement, submitter?: HTMLElement): FormData {
> It might be useful to know that submitter is optional argument here.
> How would one express that? The variable now needs to be renamed?
And two lines later:
> const name = submitter?.getAttribute("name")
It's already easy to see that submitter is optional.