51–60 of 95 posts
Explain please, why anybody would want both null AND undefined?
I do think it's a little weird, but it's useful to be able to say that "this key exists and its value is null" as opposed to "there is no such key".
> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0] Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers? 0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...
> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0] Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers? 0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...
Also, for me it's still unclear how versioning is handled. It always seems like you have to use the latest version of the .d.ts and hope it works with your actual package version.
> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.
It's a tough call, and I can see arguments for both sides. On the other side, one of the big selling points of TypeScript is that you can take your existing huge JavaScript codebase, and with little effort turn it into TypeScript with all the types being "any", then gradually add strong types as time permits. This wouldn't work if --strictNullChecks was the default and would add one more step to the migration process…
(according to https://github.com/Microsoft/TypeScript/pull/7140)
Another interesting addition is discriminated union types: https://github.com/Microsoft/TypeScript/pull/9163 This will greatly facilitate a more functional style of programming.
So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a single file that I load into a website. That last part is in need of change because you're not supposed to concatenate commonJS. So how have you been delivering your code to the browser?
Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increasingly useful as more libraries are authored in ES6 / TypeScript, as it will allow you to import the whole of a framework like Angular or React, but only ship the parts of it that you actually use in your application.
So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a single file that I load into a website. That last part is in need of change because you're not supposed to concatenate commonJS. So how have you been delivering your code to the browser?
We're experimenting with using TypeScript 2.0 for compilation, and webpack 2 for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax to ES5, but to leave the module statements (e.g. import and exports) as ES6. Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increa…
let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decor…
As to the additional checks for non-null types, I'd say that async/await would be far more welcome at this point... it's one of the few reasons that those using TS are still running their output through babel after.
Personally, I'm not a fan of TS, but can see why others would like it... I'm pretty good with ES2016 + Stage-1 via Babel...
Another interesting addition is discriminated union types: https://github.com/Microsoft/TypeScript/pull/9163 This will greatly facilitate a more functional style of programming.
Union types without destructuring/pattern matching seems really strange, doesn't it? Special casing a certain property name and converting types based on a string comparison?
Earlier quoted context omitted.
Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also c…
> let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too an…
|>
> function2