Perhaps menu-driven refactoring is overrated? (much like IDE generated getter/setter code, which is solving the wrong problem)
What do you mean? It's the typescript compiler that catches your errors. The IDE stuff is nice to have, but it's not the main benefit typescript adds to refactoring. Typescript doesn't rely on an IDE.
I work with a typescript project, and the classes of errors that are caught by the TS compiler are not worth the hassle of having to use typescript.
I've also been trying to derive a good TS pattern for redux Actions/Reducers. Do you have any code examples online that you could point me to?
I've been using discriminated unions on TS 2 to do this, and works quite well. Example: const INCREMENT: "increment" = "increment"; const DECREMENT: "decrement" = "decrement"; interface Increment { type: typeof INCREMENT; payload: { inc: number; }; } interface Decrement { type: typeof DECREMENT; payload: { dec: number; }; } interface State { count: number; } type Actions = Increment | Decrement; function reducer(stat…
Yes, I'm doing basically the same (define constant a as literal type, then use "typeof" operator to define action type, and then create alias for all Actions using union type).
That's one of the reasons why I miss possibility to tell what is the type of the object that function returns. So I could do something like this (hypothetical syntax)
const INCREMENT: "increment" = "increment";
const DECREMENT: "decrement" = "decrement";
function increment(inc: number) {
return {
type: INCREMENT,
inc
};
}
function decrement(dec: number) {
return {
type: DECREMENT,
dec
};
}
type Actions =
returntypeof increment
| returntypeof decrement;
So I won't need to write action type when I have action creator method.
I hope that in future Typescript devs will add some feature to allow this kind of pattern.
And languages like Rust, which are working toward eliminating the need for a garbage collector.
I think I would rather do future "systems level" work in Rust than C, but I'm not sure it would eliminate the desire for automatic memory management in a casual or "ENTERPRISE!!!" (... no intelligent life here, Scottie) app :-)
I haven't used Rust enough to comment myself, but other people have said that Rust essentially does have "automatic" memory management (in the sense that you must manage the memory in order to get your program to compile). People say it works most of the time, at least. Rust is trying to make that as painless as possible, so it'll be interesting to see how painless it really is.
The pipeline operating is super speculative. I would suggest not using it yet.
It's still early, but it makes Rx code much easier to read. So long as you're comfortable using Babel for transpilation, it doesn't really matter whether or not it's TC39-approved.
It'll matter in 3 years when you have an app that's full of rejected ideas.
That's the problem I have with the Babel-everything mentality of a lot of developers, they don't realize that they are essentially created their own quasi-language that they'll have to support on their own.
Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React. Also, since this seem to be a popular misconcept…
After I saw tsx, I wondered why anyone uses anything else. My goal for my next project is to use typescript and tsx or work somewhere that does! :)
Any tips on using Dart with mobile from Windows? I only need to target Android, not iOS. I haven't touched Dart for over a year, but the Flutter page seems like it is on HTML, not native, and it only specifies Linux or OS X dev machine.
Looks like Flutter dev for Windows isn't ready yet, but is planned. I believe Flutter is native, check out the system architecture: https://docs.google.com/presentation/d/1cw7A4HbvM_Abv320rVgP...
Yeah, I did finally, thanks!
I'm going to try it on my Linux box. The only disadvantage I can see for my eventual needs after a second reading is the lack of 3D support. I can get by with 2D for most of my stuff, but for games, I need the 3D hook.
I'll have to see how easy it is to customize the Dart-provided widgets. Might be easier than creating them from scratch in OpenGL via the NDK.
Immutable.js ( https://facebook.github.io/immutable-js/ ) doesn't have the greatest typescript type annotations. Due to limitations of TypeScript, there is no way to write types for immutable.js heterogenous maps (homogenous Maps and Vectors are fine though). Since immutable.js collections are recommended to be used with redux, and no one wants to bother using IMJS records instead of just maps, the types end up being…
Functional programming is quite old and I wouldn't call it a trend. I'd say it's more like an industry getting better at its craft, similar to the transition toward strong typing.
Within JavaScript, (pure) functional programming is a new trend.
Speaking as the person who implemented JSX support for TypeScript, I question the premise! JSX support (and implementation of React semantics for typechecking that JSX) was a very popular feature request. I can tell you just from how quickly people notice when something JSX-related changes in the nightly build that there are a lot of people using TypeScript with React. Also, since this seem to be a popular misconcept…
i'm one of the people whose team has benefited greatly from your work on .tsx, thanks for the great tool! i suspect a great many typescript users are not open source.
tsx refactoring and type checking is mind blowingly awesome. This feature alone makes me choose tsx over angular templates. angular templates are very loose and no property way of type checking it. I've seen some terrible mistakes in angular templates when refactoring.
I do not believe compilation nor a type system belong in JavaScript. It's better to have something like "Flow" that does static analysis of the code as you write. I might even go as far as putting on a "tin foil hat" and state that Typescript is a trick to lock you into their proprietary ecosystem of expensive tools that everyone have to buy into just to communicate with you once you are locked in.
Why not ? I only see advantages for static typing for a small cost of time: you prevent most of Type Error from happening, you get automatic auto-completion, refactoring errors are easier to catch and feel safer. Either way, you need to specify the type of the arguments in the documentation of your function (I can sometimes even find the C# LINQ's function I'm looking for just by looking at the return type of the lis…
Because JavaScript has semantic types like List, Date, Number, String, Boolean, witch can easily be figured out by their context, like age is a number, name is a a string, married is a boolean, children is a list, born is a date, and adding type declarations are unnecessary, witch would only add extra cognitive load to the programmer. It's possible to be an productive JavaScript programmer without even knowing about types and how they are implemented.
If the programmer however makes a mistake, like concatenating name and age, it will be caught during runtime, manually testing, automatic testing, runtime testing, or real time static analysis, or all of these five.
Being able to concatenate and mix types like number and string is also a language feature that avoids a lot of boilerplate code.
Looks like Flutter dev for Windows isn't ready yet, but is planned. I believe Flutter is native, check out the system architecture: https://docs.google.com/presentation/d/1cw7A4HbvM_Abv320rVgP...
Yeah, I did finally, thanks! I'm going to try it on my Linux box. The only disadvantage I can see for my eventual needs after a second reading is the lack of 3D support. I can get by with 2D for most of my stuff, but for games, I need the 3D hook. I'll have to see how easy it is to customize the Dart-provided widgets. Might be easier than creating them from scratch in OpenGL via the NDK.
What about using a combination of StageXL and ThreeJS?
Then use Cordova to package your HTML5-based app?