Integrate static typechecking via babel / flow about neos-ui HOT 12 CLOSED

What about TypeScript, guys? It is backed by Microsoft and Google, getting some proper traction in JS world as Angular 2 is written in it. Also the tooling and IDE support is much better than Flow. Also see TS roadmap: https://github.com/Microsoft/TypeScript/wiki/roadmap .

Flow is currently only available on Mac and Linux and feeels like it has little traction. It has dependency on OCaml will probably go with full rewrite in JavaScript to make it available on Win.

These are some good resources to get grasp on Flow vs TypeScript:
https://speakerdeck.com/craigrbruce/typescript-vs-flow
https://blog.wearewizards.io/flow-and-typescript-part-1-flow
https://blog.wearewizards.io/flow-and-typescript-part-2-typescript
https://medium.com/@vivainio/typescript-is-pretty-good-d8fecf80ea0c

Personally I have some experience TypeScript only, so I can be biased. With my small team we've just finished project with Angular 2 and TypeScript (nearly ~10k LOC in .ts files) and I have to say it was pretty awesome experience.

from neos-ui.

Hey @ryzy,

thanks for the input! @bwaidelich came up with TypeScript as well in #guild-js :) I'm going to take a look at what you've posted here and evaluate if and when it is feasible to switch to TypeScript.

from neos-ui.

@dimaip @skurfuerst FYI in the recent months my task was to setup a react/redux mono-repo with flow support and I have fixed most of the issues / built workarounds.

My opinion on this matter is, that it definitely enhances the developer experience, especially for newcomers or people who are not that aware of the state structure / data model. A downside, that everybody needs to accept is that Flow's error message are a bit cryptic / hard to reason as of now and the editor integrations (at least for atom) are not 100% perfect, but once you got the hang out of it, it definitely pays off.

Question is, do we all accept this initial burden / headache? If that is the case I would be super happy to contribute flow support to the noes-ui. :) ❤️

from neos-ui.

I like Flowtype but not strongly opinionated on the subject. I guess rewriting Flowtype annotations to that ES7 stuff is easier than starting with type checking from scratch, so makes sense to go for it.

from neos-ui.

I had a look at http://flowtype.org/blog/2015/02/20/Flow-Comments.html, and I kind of like that solution, because it does not enforce a proprietary syntax - but i strongly dislike the visual mess this creates...

We have to weigh the benefits of this typechecking solution against the inevitable refactoring it is going to require some day. I'm kind of in favor for static typechecking though...

Let's wait a little with this. As the codebase grows more functional, it'll give us a better overview on whether or not it's wise to break the standards at this point.

from neos-ui.

I also had a look at flow this evening and I really like it. I think we should integrate it sooner than later to avoid a big overhaul. Flow seems like the better option since most React developers are already familiar with it. I would give it a shot tomorrow, or at least this week. What do you say @grebaldi @dimaip?

from neos-ui.

I was always for it 👍

from neos-ui.

I integrated Flow into the codebase last evening, and one evaluation of the whole codebase took more than 5 minutes, note that after 5 minutes I eliminated the process since it took to damn long.

Still, I will stick to this and will play around to see if it's only a problem with my configuration or setup.

from neos-ui.

@grebaldi do you think we should give Flowtype another try some time? I'm remembering some bugs from this year, and a lot of them could have been avoided if we had it in place...

from neos-ui.

it's not on th elist for 1.0.0; except somebody is willing to take it over.

from neos-ui.

I think this is actually a very good investment. In that case we could drop the proptypes, right?

from neos-ui.

@dimaip yep, we could drop them and optionally transform flow types into react-prop-types for the client, or even further transform all flow types into run-time type-checks using the babel-runtime package.

from neos-ui.