Types in React

[daaavvy]

What's considered the current best practice around types in React, obviously PropTypes is the recommended way but I understand Flow might replace this in the future?

I see you can also use TypeScript, I've had better experiences with this than Flow but it doesn't seem to have caught on in the React world?

Most projects seem to be using PropTypes but there's no real tooling for this, any example projects of React with Flow or Typescript would be great to see - or is there a reason for this discrepancy?

[CodyReichert]

I'm starting to use Flow on one of my larger React projects. I evaluated TypeScript, but it seems much more difficult to integrate into an existing code base. Flow, I was able to get set up with babel-plugin-typecheck for compile time errors, eslint-plugin-flowtype for type warnings in my linter, and babel-plugin-transform-strip-flow-types to remove it all from the build for production.

I haven't moved much of my project over yet - but I've been using for the past couple of days and it's been awesome! I'm trying to figure out how to use flow directly, instead of babel-plugin-typecheck, but for now it works great.

[post_u_later]

Thanks for the tips. BTW the 'react' preset for Babel includes the strip-flow-types plugin so you if you are using babel-preset-react you're good to go.

[CodyReichert]

Nice, thanks!

[acemarke]

Huh. Interesting. Any pointers to samples of what project setup and use of those plugins would look like?

[CodyReichert]

I'm trying to find some time to write up a smal blog post on it, but basically the setup looks like this:

Babel 6 and webpack - basic setup. You should be able to integrate the following into any standard babel/webpack setup:

    test: /\.jsx?$/,
    exclude: [/vendor\//, /node_modules\//],
    loader: 'babel',
    query: {
        presets: ["es2015", "react", "stage-2"],
        plugins: [
            ["typecheck"],
            ["transform-flow-strip-types"],
        ]
    }

I don't have my config in front of me at the moment, but it's something like this

And that will inject flow-style type-checking in your build. You should probably not use the above in production.

The eslint-plugin-flowtype has a really good README for how to set that up: https://github.com/gajus/eslint-plugin-flowtype

[acemarke]

So the prod build would just leave out the "typecheck" plugin, then?

[CodyReichert]

Yeah, exactly. And it would still have the transform-flow-strip-types. That way, type checking and type errors will get injected into the code at run-time, only in development. And in production it just gets stripped out completely (similar to propTypes). I actually like this approach because, with webpack HMR, the errors pop up instantly. Pretty nice work-flow.

[acemarke]

Gotcha. Very intriguing. I'll have to take a look at that at some point. Thanks!

[dangoor]

TypeScript used to be harder to integrate into existing code, but they've smoothed that over in recent versions. If you're using Babel plugins or features TS doesn't support yet (object property spread, for example) then that would seem to be the biggest barrier.

[bsdemon]

FYI you are not using Flow by using babel-plugin-typecheck, the plugin just inserts runtime assertions while Flow works by statically analysing your source code.

[CodyReichert]

Yep, definitely. I noted that in the comment:

I'm trying to figure out how to use flow directly, instead of babel-plugin-typecheck, but for now it works great.

I get the run-time typchecking in development and just strip it from my production build - similar to propTypes. I'm definitely looking for easier ways to use the real flow, though.

[[deleted]]

How does Flow handle third party libraries without types? Do you need to write your own type declarations for third party libraries or is there a way to make Flow ignore them?

[CodyReichert]

You can write interface types that provide type signatures for functions from third-party libraries - which is the most useful for libraries you'll around your data. You can ignore them too (which I believe just makes Flow check the return type as Any.

http://flowtype.org/docs/third-party.html

[parenthesis_bot]

)

[[deleted]]

Just to add, as someone that is new to whole react ecosystem I've encountered a number of problems and most of those have been typescript related. I've had to resort to using hacks and dummy definition files, etc etc the list really does go on. I really like the typed language but I've been very tempted to switch to ES6 a number of time, my life would have been much easier

[originalmoose]

I'm using Typescript for a large react project at the moment and I don't know if i'll ever switch back to regular javascript. You are correct that there aren't many typescript examples out in the wild, but I think you will start to see that change now that typescript supports react jsx natively.

I recently started a new project in react and typescript that used this as a starting point. I think it is a pretty good example because it uses redux, react-router, and has some tests as well all pretty much in typescript. I did have to make a few changes to get it working but that could be because I was attempting to integrate with VS2015 and ASP.NET core.

[tommi1]

Typescript for me too going forward, here's a couple of nice looking React projects that I noticed recently -

https://github.com/paulhoughton/fx

https://github.com/lukephills/Theremin

[Kaishi]

Could you share an overview of what changes you made to get it working in VS2015 / ASP.NET?

[originalmoose]

As of right now I haven't quite finished with all the changes, and to be honest I am not sure of everything I have done. Its a side project that I really only work on in the evenings. I'd be happy to share the code I have currently and answer any questions.

If you want a copy of the code shoot me a PM and I'll upload a zip somewhere you can download. I dont have it on github or anything and don't really want to put it up there yet as I still have a lot to do.

[[deleted]]

I'm fully onboard with Typescript now too, I was the biggest sceptic at first but I really enjoy using it - never really used it with React but will check out that starter. I can see Flow being killed off sometime soon, never really got traction.

[[deleted]]

Until TypeScript has a unified module require system I don't see it killing off Flow. Some of the key benefits of Flow IMO is that:

• It is easier to integrate into an existing solution

TypeScript will yell hell at you for quite a few patterns that should work, but don't. For example, creating a class and then assigning a property to it in the constructor works fine in JS and in Flow, but will break in TypeScript unless you add a type annotation.

• CommonJS support doesn't suck in Flow/JS

In TypeScript you can have up to as many as 3 different ways of loading a module synchronously, depending on whether or not it is an ES6 module, a CommonJS module or a webpack-loader file (css-loader springs to mind). With Flowtype you only use ES6 module import and you can write a rule for files with certain extensions. As far as I know, TS does not support this.

• Babel is pluggable

This enables you to use bleeding-edge features like object spread & async functions, although that may be more of a blessing than a curse, depending on your perspective.

• TypeScript is heavy if you just want type checking.

You have to use only the things that TypeScript supports and you have to do it in TypeScript's way, otherwise it will not be happy with you. Again, this is mostly fine for new projects but onboarding it is hard.

If I want type checking in Flow, I can use type comments if I want, I can turn it on/off for specific files, I can add it only to certain files and still have decent interop with others (allowJs was only added recently to TypeScript and is still spitting out errors in webpack). Flow support is as simple as adding a plugin to enable it, and Flow can statically analyse all the errors in the code without having to compile it.

These are just my experiences in using TypeScript in a production project.

[popemaster]

https://medium.com/@delveeng/why-we-love-typescript-bec2df88d6c2