[britch]

Early errors are good, but I think the author overstates the importance of filtering out empty strings

---

I disagree that erroring out when the app doesn't have ALL the data is the best course of action. I imagine it depends a bit on the domain, but for most apps I've worked on it's better to show someone partial or empty data than an error.

Often the decision of what to do when the data is missing is best left up the the display component. "Don't show this div if string is empty", or show placeholder value.

---

Flip side, when writing an under the hood function, it often doesn't matter if the data is empty or not.

If I'm aggregating a list of fooBars, do I care if fooBarDisplayName is empty or not? When I'm writing tests and building test-data, needing to add a value for each string field is cumbersome.

Sometimes a field really really matters and should throw (an empty string ID is bad), but those are the exception and not the rule.

[kennywinker]

Sure, but in that case string | undefined is the correct type, and turning it into string | “” isn’t helping anybody.

It’s the difference between:

if (fooBarDisplayName) { show div }

And:

if (foobarDisplayName && foobarDisplayName.length > 0) { show div }

Ultimately, type systems aren’t telling you what types you have to use where - they’re giving you tools to define and constrain what types are ok.

[britch]

I'm not sure I follow the point you're making

My example is we want to skip the div if empty or undefined. We can't throw on assignment so we leave it as as string|undefined.

When we go to display, we have to check if the string is empty anyway, right? What if it's empty in the DB or API response?

No matter what the display-component is doing something to prevent showing the empty string.

` if(fooBarDisplayName.length) { show div } `

or

` if(fooBarDisplayName?.length) { show div } `

I'm not sure what we gain by leaving it as `string|undefined`

---

If there was a "NonEmptyString" type maybe I could see where you're coming from.

I guess you could argue treating `string` like a `NonEmptyString` type seems error prone. The compiler can't verify you've done the check. At some point someone will set a string when it's empty or not do the necessary check.

You'd want a separate non-string type to make sure it's actually been parsed