Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.7

typescriptlang.org

Post reply on HN
Print view View original

151–160 of 167 posts

Re: TypeScript 3.7

#151

Post by LocalPCGuy »

erikpukinskis wrote: post #91
nicoburns wrote: post #56

Earlier quoted context omitted.

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 problem is that if you find yourself needing deep accessors, something is very wrong with your scopes. You are reaching across many levels of concerns which is a code smell. So, by making it “nice” you are making a code smell less smelly, which feels good in the moment, at the syntax level, but makes your code worse at the architecture level. This is roughly the story for all of ES6... make it “nice” to work with…

> if you find yourself needing deep accessors, something is very wrong with your scopes

I'm not sure I agree with that statement in all scenarios. For code you control, sure.

But there are many APIs that return very deeply nested structures that are inconsistent in their shape. That, in my view, is the most common place devs will need deep accessors where parts may be null/undefined somewhere in between the root object and the key they are trying to access.

Sure, they could write functions that, similar to get in lodash, expose just the values needed, at which point chaining wouldn't be needed at all in the code that deals with that value. Or it could be serialized into a class object, but again, the chain would be dealt with in the serialization. At some point, the chain needs to be dealt with and often the JSON structures from APIs are not something that's always under our control.

Re: TypeScript 3.7

#152

Post by LocalPCGuy »

nikeee wrote: post #66
andrewingram wrote: post #24

Earlier quoted context omitted.

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.

The TypeScript team is only implementing features that have a chance of 100% of landing in JS or 0%. Therefore, they wait for Stage 3. If they start implementing features at an earlier stage, there is the risk of implementing a feature with different semantics in TS than in JS, since the JS spec can still change (or event get rejected). Both cases will result in diverging languages, which is something they try to avo…

> They can't change it afterwards.

I would argue that TypeScript absolutely can change things that would be consider breaking changes. And they do have breaking changes in just about every release (sure wish they followed semver for that reason). They'd just want to be careful for big things like private fields or decorators, making sure the breaking changes get communicated publicly and loudly.

Re: TypeScript 3.7

#153

Post by machiaweliczny »

reggieband wrote: post #68
nicoburns wrote: post #56

Earlier quoted context omitted.

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…

Shouldn't that be foo?.bar?.baz ?? "default"

People writing code like this should exchange these question marks for some wisdom ;)

Re: TypeScript 3.7

#154

Post by notus »

tomconroy wrote: post #16
notus wrote: post #15

Earlier quoted context omitted.

I just use lodash get when I access object properties

`get` will destroy type inference, there's no workaround. Your output types are always `any`. The new optional chaining fixes that problem, giving you the same terseness as `get`

right but the person I was responding to isn't using typescript, they were just considering it. For a non typescript user lodash get would be fine.

Re: TypeScript 3.7

#155

Post by notus »

nerdkid93 wrote: post #20
notus wrote: post #15

Earlier quoted context omitted.

I just use lodash get when I access object properties

TS 3.7 obviates the need for using `lodash.get` or `just-safe-get`, but it does so in a way that preserves the type of your object

I'm aware :) the person I was responding to is not using typescript

Re: TypeScript 3.7

#156

Post by SirensOfTitan »

graup wrote: post #115
SirensOfTitan wrote: post #36

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 problem is that Promise.all stopped infering tuple types. Promise.all([() => A, () => B]) should be Promise but is now Promise . This issue is being tracked here and a fix seems to be already in the making: https://github.com/microsoft/TypeScript/issues/33752 https://github.com/microsoft/TypeScript/pull/33707

Yeah, thank you. I think it's questionable they shipped with this kind of regression present (especially having known about it 1 month before release), but easy fix just to override core types with the one in #33707.

Re: TypeScript 3.7

#157

Post by lucideer »

mateuszf wrote: post #146
lucideer wrote: post #140

Earlier quoted context omitted.

> TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. I'm afraid literally everything in this snippet is incorrect. The Typescript website opens with: > Typescript JavaScript that scales. Typescript is a typed superset of JavaScript that compiles to…

> Typescript is Javascript. In the same way as an Animal is a Camel.

In the same was as programming languages are not organisms.

Typescript is ECMAScript in the same way as Netscape JavaScript is ECMAScript, in the same way as ActionScript is JavaScript.

In the same was as Scheme is Lisp.

In a similar but not identical way as American English is English (similar but not identical since programming languages and spoken languages are both languages, but not actually the same thing: the analogy cannot map perfectly).

Re: TypeScript 3.7

#158

Post by paulddraper »

davnicwil wrote: post #144
paulddraper wrote: post #104

Earlier quoted context omitted.

&& ?. || ?? It's a shame JS at the beginning doubled down on the "billon dollar mistake" [1] with two(!) kinds of NULL instead of just using Maybe/Option. Ah well, if it were good it wouldn't be popular :/ [1] https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

I don't see it as two kinds of null, there is a null value, and then there is the fact that no value has ever been defined, which is undefined. It can be useful to have the latter case distinguished in a dynamic language because it can enable certain powerful patterns. At the end of the day, compressing both these cases to a single concept of null would be lossy. This may have certain advantageous implications for si…

Or, use Maybe/Option and have as many levels of nonexistence as you want.

    Option[Option[Option[T]]]
Not that it would necessarily be very useful, but choosing 2 values of nonexistence is very arbitrary.

Usually zero or one level of nonexistence is enough.

Re: TypeScript 3.7

#159

Post by paulddraper »

sieabahlpark wrote: post #132
paulddraper wrote: post #128

Earlier quoted context omitted.

> optional chaining and null coalescence are core language features of some very good languages They are features of Maybe/Option too, just in a more consistent extensible way. val a = Some(thing) val b = a.flatMap(_.part).flatMap(_.subpart) val c = Some(None) // look Ma! a nested option! > While JS might get this stuff one day I appreciate the attempt at pedantry, but TypeScript general only implements JS language f…

Show me where decorators are in the ecmascript standard. How about private variables in classes? (Hint: they're different) Typescript is a superset not just typed JavaScript.

I had actually listed decorators as a rare counterexample, but then removed it from my comment for brevity.

1. Decorators are currently TC39 Stage 2. [1]

2. Because of its unusual status, TypeScript lists decorators as "experimental, subject to change". Once the EcmaScript proposal advances, TS will ensure it is compatible with the ES standard and then remove the experimental sticker.

3. If it doesn't affect runtime, then you shouldn't expect JS to have the feature. TS private members are no different than public members at runtime; there is no need for JS to have that feature. (Note that TypeScript deliberately chooses not to name-mangle members.)

4. Sure call it a "feature and syntactic superset", but that doesn't make TS any less beholden to JS. Dedicated adherence to that property commits them to support every feature and syntax that JS adds; future-proofing means they can't really add anything that JS doesn't have or is going to have.

5. Note that TS abandoned having a standard long ago. The behavior and validity of TypeScript program is determined by "whatever tsc does" and the ES standard.

6. Again, if you need convincing that TS effectively only implements JS features, refer the linked pipeline issue, locked as "waiting for TC39."

[1] https://github.com/tc39/proposal-decorators

Re: TypeScript 3.7

#160

Post by munificent »

virtualwhys wrote: post #87
munificent wrote: post #69

Earlier quoted context omitted.

Depending on when you last looked at Dart, there's a good chance we've either fixed or are fixing the things you hate about it. What didn't you like?

> What didn't you like? That the suggested features in this open issue [1] can't be implemented soon enough :) Is there a roadmap available that would give an idea as to when x, y, z language features may be implemented? [1] https://github.com/dart-lang/language/issues/546

We don't tend to have detailed roadmaps because it risks setting people up for disappointment when schedules change. But what's roughly happening right now is:

- Extension members are basically done and out the door. (See: https://medium.com/dartlang/extension-methods-2d466cd8b308)

- Non-nullable types are well underway. All but a few corners of the design are pinned down, much of the static checking is implemented, the core libraries have been mostly migrated, and we're working through the runtime implementation, migration tests, etc.

- Next up after that, the current plan (which may change) is control over variance and stuff around pattern matching.

We're working on it.

Post reply on HN