3 ms·

The difference between Promise and optional chaining is that you can (and should) redesign your code not to need deeply nested data access. The pain of doing d

The difference between Promise and optional chaining is that you can (and should) redesign your code not to need deeply nested data access. The pain of doing deep null checks everywhere is a code smell in itself, and optional chaining just covers it up. Making a bad thing easier to do is bad. You can't redesign your code not to need asynchronous callbacks. They're fundamental, given the constraints of the language implementation. Given that, it makes sense to make them as painless as possible (and I'd argue async/await is... well, it's not good, but it's better than Promise alone).

alan_n 8y ago
Right, but sometimes that's just not possible, what then? The only option is to abstract the check into a function which just moves the problem. Or to use a third party library to do exactly what optional chaining does. When I see this argument I just think why should I have to suffer because other people don't know best practices and will produce bad code regardless of whether this exists or not? I would argue it makes a bad thing easier to read so you can actually tell what's being checked. It's already an easy thing to do, leaving things as they are is not deterring anyone, except it reads horribly. I'm not arguing too many aren't code smell, but what about when it's needed? The object check syntax proposed on the other hand, imo, does not make things clearer and is of little benefit. Also regarding callbacks, I meant you can avoid callback hell without using promises. Promises were not technically needed to solve that problem even though they're talked about as a solution to it, you can have promise hells too (and they are exactly what most beginners do with promises). But if used right, the solution is much easier to read and understand. That's how I see optional chaining.

3 ms·

The difference between Promise and optional chaining is that you can (and should) redesign your code not to need deeply nested data access. The pain of doing d

by regularfry 8y ago

alan_n 8y ago
Right, but sometimes that's just not possible, what then? The only option is to abstract the check into a function which just moves the problem. Or to use a third party library to do exactly what optional chaining does. When I see this argument I just think why should I have to suffer because other people don't know best practices and will produce bad code regardless of whether this exists or not? I would argue it makes a bad thing easier to read so you can actually tell what's being checked. It's already an easy thing to do, leaving things as they are is not deterring anyone, except it reads horribly. I'm not arguing too many aren't code smell, but what about when it's needed? The object check syntax proposed on the other hand, imo, does not make things clearer and is of little benefit. Also regarding callbacks, I meant you can avoid callback hell without using promises. Promises were not technically needed to solve that problem even though they're talked about as a solution to it, you can have promise hells too (and they are exactly what most beginners do with promises). But if used right, the solution is much easier to read and understand. That's how I see optional chaining.