131–140 of 247 posts
TypeScript works very well with React, less so with Redux/ImmutableJS. We just moved our app from Redux and ImmutableJS to mobx and it's been a treat: we now get full typing and it's much less verbose. We don't need to repeat the payload definition at every point, we have a store where we call a method and that's it. Highly recommend checking out mobx if you use TS.
https://swlaschin.gitbooks.io/fsharpforfunandprofit/content/...
What I loved about them is they show how a different type system and language design can massively reduce code size and errors.
After reading them I felt frustrated back in JavaScript or C# or any other language I use regularly.
Are Typescript and Flow missing the forest for the trees?
The fact that components props are verified by compiler instantly when I type is a big win. I believe with PropTypes you can't specifically describe what is the shape of your data, for example object with property of such name and the value of this property is object with other concrete properties. Or array of objects with specific property. In pure react you only have "React.PropTypes.object" and "React.PropTypes.array" in TypeScript you can say "{ foo: string, bar : { fieldNum : number}}" or "{foo: string}[]".
Some other observations:
- I use Typescript 2.0 RC, because it has union types [0] and it works great with Redux reducers. It's super cool!
- I don't miss spread object operator that much, it would be nice but I'm fine with some utils function that can even verify that I "override" property that exist is source object[1] (I mean creating new object with changed properties)
- What I really miss is the ability to say that what is the return type of the method. There is "typeof" operator in typescript for telling what is the type of particular object, I would like something like "returntypeof". Because now I always need to write the type of an action and very often it could be inferred from action creator function. Or I need to write type to describe what will be returned by Redux's "mapStateToProps" function, and sometimes this object can be big.
[0] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T... [1] https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
Earlier quoted context omitted.
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…
I see, but using types for some parts of your code is still better than using none. And yes, actually I am using MobX, too, it's really a good choice for React. Although I miss redux-saga sometimes.
Does such a thing exist for Flow? Could it? If it did that would go a lot further to push me to flow than that it just catches more errors. I get huge productivity gains from my editor helping me with API completions etc...
I've been using React + Redux + Typescript stack and I've been quite happy with it (It's hard for me to image how you could do big refactoring without TS). The fact that components props are verified by compiler instantly when I type is a big win. I believe with PropTypes you can't specifically describe what is the shape of your data, for example object with property of such name and the value of this property is obj…
React.PropTypes.shape({
foo: React.PropTypes.string,
bar: React.PropTypes.shape({
fieldNum: React.PropTypes.number
})
})
Earlier quoted context omitted.
> It would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain. As someone who has written a long tutorial, this makes total sense. When I was first looking at the react ecosystem, it was very frustrating because of the high cost of picking pieces to work together. I really liked http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial... becaus…
This is basically my frustration with the whole trend toward smaller pieces over big monoliths. I don't need a best-in-class every tiny little thing; I just want reasonable tools I can expect to work together well.
Earlier quoted context omitted.
Because freedom? Typescript is a superset of JavaScript, which means all JavaScript is valid typescript. So you're never faced with the difficult choice of locking yourself to one language/platform. JavaScript is awesome, it just doesn't scale to large projects because you cannot efficiently refactor it. Typescript solves this problem beautifully. You can easily add whatever type information you need to effectively w…
Does that include ES6 ? What parts of JS do they consider a subset of typescript ? Can i keep my type declarations in a different file than my .js code like flow does ? (thus ensuring compatibility while keeping the functionality of typescript) How far can i go with typescript until i need to use babel ?
Yes.
> What parts of JS do they consider a subset of typescript ?
Everything that's standardized.
> Can i keep my type declarations in a different file than my .js code like flow does ?
Yes.
> How far can i go with typescript until i need to use babel ?
Pretty much as far as you want, although you may have to wait a little bit longer.
BTW, stop inserting spaces before your punctuation. It's super aggravating.
TypeScript works very well with React, less so with Redux/ImmutableJS. We just moved our app from Redux and ImmutableJS to mobx and it's been a treat: we now get full typing and it's much less verbose. We don't need to repeat the payload definition at every point, we have a store where we call a method and that's it. Highly recommend checking out mobx if you use TS.