Neos-ui: Integrate static typechecking via babel / flow

[Inkdpixels]

I've just discovered this plugin: https://github.com/codemix/babel-plugin-typecheck

It kind of enables static typechecking for functions, in ES7 there may be Trademarks and Guards, which kind of strive into the same direction.

The question is, do we want to integrate such a plugin, even though its syntax may heavily change in the upcoming months?

I think static typechecking in functions would enhance the code quality greatly, though I am aware that this may be a to unstable feature of the next ES version.

What do you think @dimaip @skurfuerst @grebaldi

[dimaip]

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.

[grebaldi]

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.

[Inkdpixels]

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?

[dimaip]

I was always for it :+1:

[Inkdpixels]

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.

[ryzy]

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.

[grebaldi]

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.

[dimaip]

@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...

[skurfuerst]

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

[Inkdpixels]

@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. :) :heart:

[dimaip]

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

[Inkdpixels]

@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.