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

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

121–130 of 226 posts

Re: Announcing TypeScript 2.1

#121

Post by Noseshine »

thejameskyle wrote: post #106
TAForObvReasons wrote: post #80

Earlier quoted context omitted.

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser! As an example, the flow checker will read the annotations from `function f(n/ :number /, s/ :string /) { ... }` but since they are commented in the source code your JS engi…

Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps: 1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything) $ npm install --save-dev babel-plugin-transform-flow-strip-types Then update your `.babelrc`: { plugins: ["transform-flow-strip-types"] } 2. Setting up with ESLint $ np…

For eslint I'm using plugin "flowtype", and under "extends" I have "plugin:flowtype/recommended". Do you happen to know what's different compared to the eslint-flow package you mention? I took the first one I could find, didn't want to spend hours with the eslint part of using Flow since I was busy with all the errors reported by Flow during the conversion process.

EDIT:

Ah I think I get it, it's for editors that don't interface with Flow but only with eslint. Well, since WebStorm has Flow support - even though it's new and there are a few tickets open - I guess I should stick with the plugin that I already chose.

Re: Announcing TypeScript 2.1

#122

Post by jhchen »

lacampbell wrote: post #119

How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing. Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.

In theory source maps is the answer but personally this has only worked some of the time. When it does work though it is magical and exactly answers your question of debugging in the browser at the source level.

Re: Announcing TypeScript 2.1

#123

Post by pimterry »

k__ wrote: post #103
pimterry wrote: post #86

Earlier quoted context omitted.

That would defeat the point of 'any', right? It's for variables that you want to allow to do anything (including be a T) without the compiler complaining. If you don't want that behaviour, don't given x 'any' type. In that case there I'd probably use '{}' instead, and then use type guards ( https://www.typescriptlang.org/docs/handbook/advanced-types.... to convince TypeScript that it's a T (whatever that means).

tslint has a rule to prohibit the use of any. maybe this is worth an option for tsc

Maybe, but I think there's a lot of cases where you want to be able to use 'any' explicitly. Tsc does already have noImplicitAny, so you have to have opted in to this behaviour.

Re: Announcing TypeScript 2.1

#125

Post by edblarney »

thejameskyle wrote: post #116
edblarney wrote: post #101

Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp t…

> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.

Yes, it needs to be created 'right there' - but not in the context of other modules loads.

I doubt that a strict interpretation requires that it does so before other modules are loaded.

I suggest that 'right there' , i.e. the execution context can be delayed until mods are loaded.

One could argue that all modules could be loaded before execution context.

In Java, for example, you do not have this problem and yet, in Java we would say the attribute is initialized 'right there' as well.

Obviously, when I say 'loaded' I don't mean 'executed'.

In any event, it's a problem.

Re: Announcing TypeScript 2.1

#126

Post by ggregoire »

billti wrote: post #120
ggregoire wrote: post #40

Earlier quoted context omitted.

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…

If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it c…

Nice catch! Yeah, that makes sense.

As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript?

(I use the official flow-for-vscode extenstion, idk if it's relevant)

Edit: Ok I just tried and it works, even with the extension disabled.

  type Foo = {
    a: boolean,
    b: string,
  }

  var foo: Foo = {
      a: true, // Find all references on "a" here...
      b: "hello"
    };

  foo.a = false;
  bar(foo);

  function bar(obj: Foo) {
    obj.a = false; // Found it.
  }

Re: Announcing TypeScript 2.1

#127

Post by frankwallis »

mhink wrote: post #99
euroclydon wrote: post #30

One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target…

They're getting better at describing which features are shimmed, but the easiest way to check is by running a single plugin on a bit of code and seeing for yourself. For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.) With the following input: var foo = { x: 1, y: 2 }; var bar = { a: 3, b:…

Deduplication of helper methods is now available in typescript too, using the 'importHelpers' compiler option. It will automatically add import statements to include the helpers from the 'tslib' package, see https://github.com/Microsoft/tslib

Re: Announcing TypeScript 2.1

#128

Post by curveship »

seattle_spring wrote: post #32
icholy wrote: post #26

Earlier quoted context omitted.

The new type system features are: keyof, lookup types, and mapped types. Does flow have even one of these?

$Keys for keyof, $MapObj for mapped types. They are sorely missing lookup types though.

I can't seem to find any info online about $MapObj? I searched the docs, google ... nuthin'. Am I just missing something?

Re: Announcing TypeScript 2.1

#129

Post by autogol »

lacampbell wrote: post #119

How does the development cycle work? With plain JS I load up my html page in browser (chrome) and head to the console to check for errors in the JS. Then I do user testing. Can type-script be debugged by a browser on a source code level - ie not on a transpiled level? If not, I am not sure if it's worth it. And I say that as someone who is a huge fan of explicit optional typing.

The development cycle is basicaly this: write Typescript code in a .ts file, transpile to a .js file, load .js into html. Transpiling can be handled by the IDE or by a build tool like gulp. For example, IntelliJ Webstorm has a built-in file watcher that tracks changes to .ts files and transpiles accordingly.

Typescript can be debugged on a source code level, using source-maps. Webstorm and VS Code have built-in or plugin solutions. I heard some people complaining about issues, but i had a pretty smooth experience so far.

Re: Announcing TypeScript 2.1

#130

Post by billti »

ggregoire wrote: post #126
billti wrote: post #120

Earlier quoted context omitted.

If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it c…

Nice catch! Yeah, that makes sense. As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript? (I use the official flow-for-vscode extenstion, idk if it's relevant) Edit: Ok I just tried and it works, even with the extension disabled. type Foo = { a: boolean, b: string, } var foo: Foo = { a: true, // Find all references on "a" here... b: "hello" }; f…

I don't know, but generally call-site inference has a couple of notable issues:

- If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function).

- Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).

Post reply on HN