Parse, Don't Validate – In a Language That Doesn't Want You To
cekrem.github.io
Parse, Don't Validate – In a Language That Doesn't Want You To
1–10 of 107 posts
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#2This feels right, and I also have never done it (or had the guts to get others to do it).
The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right.
The classic answer is to move the logic inside the domain object, or have a helper function outside the object, so you aren't constantly checking for field presence/absence, but are instead writing the logic once and calling some code.
I'm not sure in practice types can help with this. But I'd love to be proven wrong.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#3[flagged]
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#4This feels right, and I also have never done it (or had the guts to get others to do it). The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right. The classic answer is to move the l…
if a user with/without phone number are equally valid states to be then types won't help you much. I think it's more about writing
class User{phone: ?PhoneNumber}
class User{phone: ?string}.Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#5This feels right, and I also have never done it (or had the guts to get others to do it). The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right. The classic answer is to move the l…
I think this is a slightly different problem. The absence of an optional field, if that's a legal state, is meaningful every time you use the type, so you encode it on the field: `phone: ValidPhoneNumber | null`. When it's not null you're still guaranteed a valid phone number. When it is null, that's a legal state you have to handle and which is domain logic, not validation you forgot to do.
The combinatorial explosion you're picturing only shows up if you make a separate type per combination of present fields, but you don't need to. An independent optional field stays one `T | null`. You only reach for distinct types when fields are correlated and present together because they represent a state, and then it's a discriminated union on a status field, which is N states, not 2^N.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#6Don't forget to freeze the objects
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#7As a new TypeScript user these are concepts that have greatly helped me simplify my code and improve reliability discrete of testing. Many LLMs guide in this direction if you loosely ask them, but having a concise post like this with the what and the why is fantastic as reference material. The suggestion to use Separation and a Linter rule is something I'm going to immediately look into for my current project. Great post!
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#8This feels right, and I also have never done it (or had the guts to get others to do it). The reason I've not is - say there's an optional field. Currently we call that null, probably, and check each time if it's there or not. I could instead make a type, like User and UserWithPhoneNumber. Should we be making types for each combination of present/absent fields? That can't be right. The classic answer is to move the l…
if a user with/without phone number are equally valid states to be then types won't help you much. I think it's more about writing class User{phone: ?PhoneNumber} over class User{phone: ?string}.
To expand and give some notion of good taste:
It's more about writing
struct User {phone: MaybePhoneNumber} // give or take, it's a monoid
struct User {phone: Option}Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#9We should make authors disclose how much AI was used to write an article. This reeks of Opus 4.8.
Re: Parse, Don't Validate – In a Language That Doesn't Want You To
#10Meta: in addition to upvotes and downvotes, we almost need a slop/not-slop slider.
This one barely scrapes by at what feels like 30-40% "slop": "honestly", "the one thing", etc...
...but I did learn something about "Brand" types, and have personally tried to do more of "parse don't validate" in my own code.
Recently I did this similar trick for `exec( ValidExecutable(...) )` [python], where it required tagging/washing through a private function/variable to "get" the private bit.
All the scanners tend to light up when they see "exec" at all (eg: `exec( "pandoc" )` for PDF generation), but I needed to hard code a few "expected" pandoc locations so the imaginary hackers couldn't shadow "pandoc" on a path location they controlled.