Good video as always man, and I totally agree! A consistent, reliable interface is always a delight to work with. However, I think a lot of the time this issue comes from trying to make an API/service more flexible, by allowing it to perform essentially 2-3 different actions, and thus returning a combination of nullish values from the results of the actions, making the service & its interface unreliable.
I do like this approach and it's not something I utilise enough. I'm a big golang fan and it handles "missing" data in a similar way, that being just returning a concrete class but with empty fields similar to your empty username check at the end
Exactly, Go really shines at this. I'd say, anything one can do at any given place, that being a utility function or a class, makes the code and the data "cascade" way better throughout the entire system. One simple check and "normalization" can ruin the entire path, and make the code convoluted with unnecessary, and as I call them, lazy/convenient checks.
@programmer-network would you say you'd always rather a call return a concrete type then it's up to the invoker to determine whether that is valid data to continue? Thinking about default values against a type vs a null return. I suppose this breaks rest conventions if a not found is now an "empty" 200, but rest is fairly arbitrary these days anyway
I'd say, null is also fine to return in most cases, as I illustrated in the video, it's very common and clean to check for the presence of something. E.g. if this thing is null, handle that as a separate case. As I also showed with the HTTP example, often times, one could return just the status code, e.g. 404, but it's purely contextual. I'd say, the most important thing is though when the data is actually returned. This is where interfaces get messed up, as often time, the data you get is unstable, aka, you might get this, or that, who knows? But I'd say, as long as these are broken into services, or [Insert Pattern Here] and properly used/composed together, things will workout fine. What I've seen a lot, especially past couple of years, a lot of developers fail a lot understanding the importance of stable frontend facing API, and importance of delivering as perfect data to the UI as possible. A lot of business logic and transformations are being moved to the client side, which is why modern client side Javascript is so messed up and bugged.
Interesting video incase of user is null I usually set user to empty object if it doesnt exist so in frontend I check if Object.keys(user).length === 0 then (redirect to login page) etc.
I'm noob in JS, but wrote down a quote from Primeagen: "if you want to build robust programs, you have to use errors as values, you can make it work with try catch but it is a ton of handling". Note: JS is a try catch language.
Hi Jero. Javascript uses exception handling, and is vastly different than e.g Go, where errors are treated as values. "You have to use errors ad values to build robust..." is a false claim, as there are various ways to handle errors. You can of course achieve similar results in Javascript by wrapping each function block in try/catch and return an object with value/error but that has other performance implications. I wonder though, what in this video made you think of error handling, as what we discussed in this video was not related to errors? Thanks a bunch for commenting.
Hey Alex, on one of your streams I found js library that enables collaboration features you used on letter T as I remember. Can you tell me what it was? I can't find it :(
Interesting and practical
Good video as always man, and I totally agree!
A consistent, reliable interface is always a delight to work with.
However, I think a lot of the time this issue comes from trying to make an API/service more flexible, by allowing it to perform essentially 2-3 different actions, and thus returning a combination of nullish values from the results of the actions, making the service & its interface unreliable.
I do like this approach and it's not something I utilise enough. I'm a big golang fan and it handles "missing" data in a similar way, that being just returning a concrete class but with empty fields similar to your empty username check at the end
Exactly, Go really shines at this.
I'd say, anything one can do at any given place, that being a utility function or a class, makes the code and the data "cascade" way better throughout the entire system.
One simple check and "normalization" can ruin the entire path, and make the code convoluted with unnecessary, and as I call them, lazy/convenient checks.
@programmer-network would you say you'd always rather a call return a concrete type then it's up to the invoker to determine whether that is valid data to continue? Thinking about default values against a type vs a null return.
I suppose this breaks rest conventions if a not found is now an "empty" 200, but rest is fairly arbitrary these days anyway
I'd say, null is also fine to return in most cases, as I illustrated in the video, it's very common and clean to check for the presence of something. E.g. if this thing is null, handle that as a separate case. As I also showed with the HTTP example, often times, one could return just the status code, e.g. 404, but it's purely contextual.
I'd say, the most important thing is though when the data is actually returned. This is where interfaces get messed up, as often time, the data you get is unstable, aka, you might get this, or that, who knows?
But I'd say, as long as these are broken into services, or [Insert Pattern Here] and properly used/composed together, things will workout fine.
What I've seen a lot, especially past couple of years, a lot of developers fail a lot understanding the importance of stable frontend facing API, and importance of delivering as perfect data to the UI as possible. A lot of business logic and transformations are being moved to the client side, which is why modern client side Javascript is so messed up and bugged.
@programmer-network yeah makes sense to me thanks, full object or nothing is probably the best approach
Thanks.
Interesting video incase of user is null I usually set user to empty object if it doesnt exist so in frontend I check if Object.keys(user).length === 0 then (redirect to login page) etc.
I'm noob in JS, but wrote down a quote from Primeagen: "if you want to build robust programs, you have to use errors as values, you can make it work with try catch but it is a ton of handling". Note: JS is a try catch language.
Hi Jero. Javascript uses exception handling, and is vastly different than e.g Go, where errors are treated as values.
"You have to use errors ad values to build robust..." is a false claim, as there are various ways to handle errors.
You can of course achieve similar results in Javascript by wrapping each function block in try/catch and return an object with value/error but that has other performance implications.
I wonder though, what in this video made you think of error handling, as what we discussed in this video was not related to errors?
Thanks a bunch for commenting.
Hey Alex, on one of your streams I found js library that enables collaboration features you used on letter T as I remember. Can you tell me what it was? I can't find it :(