51–60 of 167 posts
Optional Chaining also coming soon to create-react-app, planned for v3.3 (current release is react-scripts@3.2.0) - https://github.com/facebook/create-react-app/pull/7438 I think they're just waiting on support for the new syntax in prettier.
However, in JS itself, it might cause developers to lose track of what can be null/undefined in their code. In case they start to "fix" stuff by throwing in some "?." because they don't know better, the code maintainability will degrade a lot.
Maybe I'm just pessimistic. Let's see how it will perform in the field!
Does the function argument (i.e. the template string) get evaluated regardless of the optional chaining or does it match up with the “roughly equivalent” code? log?.(`Request started at ${new Date().toISOString()}`); // roughly equivalent to // if (log != null) { // log(`Request started at ${new Date().toISOString()}`); // }
Why would it not match up with the example given? They provided it so you'd know the answer to your question.
The situation that popped in my mind was something like: f?(++a)
Normally you’d expect the side effects incrementation to occur prior to the start of the function invocation. If the function is not evaluated it’s not clear from the article if increment will occur.
The optional chaining and null coalescing operators are very nice. Dart has had those for several years and they really do come in handy.
Optional Chaining also coming soon to create-react-app, planned for v3.3 (current release is react-scripts@3.2.0) - https://github.com/facebook/create-react-app/pull/7438 I think they're just waiting on support for the new syntax in prettier.
Is it not bizarre that you're blocked on a syntax formatter to make a release? If that's what's happening, it sounds like prettier should be core and non-optional, the same way gofmt is.
I really like the optional chaining operator for statically typed languages. Especially in TypeScript where you have the nullabilaty information baked into the type system. However, in JS itself, it might cause developers to lose track of what can be null/undefined in their code. In case they start to "fix" stuff by throwing in some "?." because they don't know better, the code maintainability will degrade a lot. May…
e.g. You can do:
foo?.bar?.baz || "default";
(foo && foo.bar && foo.bar.baz) || "default";
Optional Chaining also coming soon to create-react-app, planned for v3.3 (current release is react-scripts@3.2.0) - https://github.com/facebook/create-react-app/pull/7438 I think they're just waiting on support for the new syntax in prettier.
Is it not bizarre that you're blocked on a syntax formatter to make a release? If that's what's happening, it sounds like prettier should be core and non-optional, the same way gofmt is.
For those that are curious, here's the error that 3.7 introduced:
Type 'SinonStub' is not assignable to type 'SinonStub'.
Type 'any[]' is missing the following properties from type '[string, RequestBody, (RequestOptions | undefined)?]': 0, 1
I really like the optional chaining operator for statically typed languages. Especially in TypeScript where you have the nullabilaty information baked into the type system. However, in JS itself, it might cause developers to lose track of what can be null/undefined in their code. In case they start to "fix" stuff by throwing in some "?." because they don't know better, the code maintainability will degrade a lot. May…
It's nice for situations where you want to access a deeply nested prop, and you only care whether the whole path is there or not. Saves you having to add a seperate check for every level of the hierarchy. e.g. You can do: foo?.bar?.baz || "default"; Rather than: (foo && foo.bar && foo.bar.baz) || "default"; Agree that developers can be careful about nullability (in fact I pulled someone up on this in a code review ea…
The real bug was that the property in question should never be null/undefined in the first place. It was a lot harder to find the error.
Also, I've seen some typos (or missed renames) being unnoticed without any errors. This caused some weird behavior in the frontend where there was no exception but there is definitely something wrong. Or, worse, the bug is never noticed and other code depends on that behavior.
So if the language is statically typed, the feature is awesome because the cases mentioned above will trigger a compile time error. I've seen some misuse in dynamically typed ones.
I really like the optional chaining operator for statically typed languages. Especially in TypeScript where you have the nullabilaty information baked into the type system. However, in JS itself, it might cause developers to lose track of what can be null/undefined in their code. In case they start to "fix" stuff by throwing in some "?." because they don't know better, the code maintainability will degrade a lot. May…
It's nice for situations where you want to access a deeply nested prop, and you only care whether the whole path is there or not. Saves you having to add a seperate check for every level of the hierarchy. e.g. You can do: foo?.bar?.baz || "default"; Rather than: (foo && foo.bar && foo.bar.baz) || "default"; Agree that developers can be careful about nullability (in fact I pulled someone up on this in a code review ea…