41–50 of 167 posts
The optional chaining and null coalescing operators are very nice. Dart has had those for several years and they really do come in handy.
For this code: const x = [1,2]; const y = x[666]; const z = y + 3; Is there a way for TypeScript to flag the last line as a type error? TypeScript will say "y" has type "number" when "x[666]" returns undefined. Why does TypeScript not say the type of "y" is "number | undefined"?
Perhaps explicitly setting the types might do it? const x: number[]= [1,2] const y: number | undefined = x[666] const z: number = y + 3 EDIT: Just tried, still works
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()}`); // }
I feel really excited about 3.7. Optional chaining and null coalescing will clean up a TON of code. ... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.
The result should instead be a tuple, but IDK how well tuple size inference would work in a case like that.
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()}`); // }
let bar: any, log: any;
log?.(`foo ${bar()}`);
// becomes
var _a;
var bar, log;
(_a = log) === null || _a === void 0 ? void 0 : _a("foo " + bar());Earlier quoted context omitted.
https://www.typescriptlang.org/play/index.html#code/MYewdgzg... Using `as const` will report both the 2nd and 3rd lines as type errors. You've been able to do this in TypeScript for a while even before they introduced the `as const` syntax.
Thanks, you can still trick it with this though (there's no type error): const x = [1, 2] as const; const r = 666 + 1; const y = x[r]; const z = y + 3;
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()}`); // }
Earlier quoted context omitted.
Not really https://github.com/microsoft/TypeScript/issues/9235 Though with tuples, etc. being defined, maybe it's worth re-examining.
Thanks. Is there a pattern for array access that helps with my example? Is the only option to define your own safe access function like "function safeGetFromArray (array: T, index:number): T | undefined"? I haven't tried it yet but it looks like the new optional element access feature is only checking if the array itself is defined, not if the array index is defined.
Otherwise, you're left to creating a wrapper function and a custom ESlint rule.
Edit: found it https://github.com/microsoft/TypeScript/issues/13778#issueco...
The suggestion is to maintain your own copy of `index.d.ts` with the array indexing interface modified. Yikes!
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()}`); // }
I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.
I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it's a stage 3 proposal in JavaScript too, so is likely to be widely supported soon.