I think invariant is over engineered. In Javascript one can use || to execute something based on a condition. Then the function translates to isValid || throwit(...)
Sometimes you want to be more specific. Instead of x % 2 == 0 you say isEven(x) and now you can read the code better. Of course, then you might want to get creative and check that the parameter of isEven is an integer number first and then others get creative and check is something is an integer with if (isEven(x) || isOdd(x))... =))
In the case you described it seems that you are going in the other direction. In fact having it written as if (!condition) throwSomething(...) is even more readable. I actually can't wait for having some metadata info in my language so I can do something like assertNotNull(x) with something like
function assertNotNull(x) {
if (x===null || x===undefined) {
throw new NullAssertError(metadata.parameters[0].name+' cannot be null');
}
}
Instead of going for a superfluous invariant function, I would go for specific and readable stuff like assertDateLargerThan and assertCustomerIsSatisfied and stuff like that. Surely you see I am a .NET developer, but that's my two cents :)
My conclusion is that I want to describe what I want to do, then make the code understand what I meant, rather than the other way around.
I kinda get your point! You think, that invariant is too generic and would prefer having a specific function for each use case to make code more readable.
It seems like a valid point to me, especially if we talk about the backend, where code doesn't need to be sent to the client and parsed on its side.
Thanks for adding value to the discussion 🙏🏻
It's so cool to communicate with experienced devs!
If you use TypeScript, a useful version of invariant is tiny-invariant:
importinvariantfrom'tiny-invariant';consttitle:any=getValueFromSomewhereUntrusted();// At this point TS will type 'title' as 'any'invariant(typeoftitle==='string');// At this point TS will type 'title' as 'string'
Because of the use of asserts at this source-line you're dropping a hint to the type-engine about what you've called invariant on.
I think invariant is over engineered. In Javascript one can use || to execute something based on a condition. Then the function translates to isValid || throwit(...)
I agree with you for the most part.
It seems like invariant is one of these weird utilities, like is-odd/is-even.
Sometimes you want to be more specific. Instead of x % 2 == 0 you say isEven(x) and now you can read the code better. Of course, then you might want to get creative and check that the parameter of isEven is an integer number first and then others get creative and check is something is an integer with if (isEven(x) || isOdd(x))... =))
In the case you described it seems that you are going in the other direction. In fact having it written as if (!condition) throwSomething(...) is even more readable. I actually can't wait for having some metadata info in my language so I can do something like assertNotNull(x) with something like
Instead of going for a superfluous invariant function, I would go for specific and readable stuff like assertDateLargerThan and assertCustomerIsSatisfied and stuff like that. Surely you see I am a .NET developer, but that's my two cents :)
My conclusion is that I want to describe what I want to do, then make the code understand what I meant, rather than the other way around.
I kinda get your point! You think, that
invariant
is too generic and would prefer having a specific function for each use case to make code more readable.It seems like a valid point to me, especially if we talk about the backend, where code doesn't need to be sent to the client and parsed on its side.
Thanks for adding value to the discussion 🙏🏻
It's so cool to communicate with experienced devs!
If you use TypeScript, a useful version of invariant is tiny-invariant:
Because of the use of
asserts
at this source-line you're dropping a hint to the type-engine about what you've calledinvariant
on.Yeah, you're right. It's so simple yet useful difference.
Thanks for adding value!