All in one file works, separate files do not work

[rosskevin]

Test repo: https://github.com/rosskevin/test-react-flow-types

flow-bin@0.59.0. Same results with 0.58.0, 0.57.3
react-flow-types@0.2.0-beta.6

All in one

The allInOne.js works fine, which is the same in try flow

Considering that it might be a problem with the imported type Translate, I have further simplified the repo (though left the more complicated case as a branch)

Separate files

Does not work.
See index.js

TL;DR

yarn flow should work for all files in this repo.

yarn flow                                                                                                                                                                                                                                                                                                  ✘ 1 
yarn run v1.3.2
warning package.json: No license field
$ flow --show-all-errors
Error: src/index.js:8
  8:     <ClassTest />
         ^^^^^^^^^^^^^ props of React element `ClassTest`. This type is incompatible with
  6: class ClassTest extends React.Component<{ t: Function }> {
                                             ^^^^^^^^^^^^^^^ object type. See: src/ClassTest.js:6
  Property `t` is incompatible:
      6: class ClassTest extends React.Component<{ t: Function }> {
                                                 ^^^^^^^^^^^^^^^ property `t`. Property not found in. See: src/ClassTest.js:6
      8:     <ClassTest />
             ^^^^^^^^^^^^^ props of React element `ClassTest`


Found 1 error

---

@rsolomon - I'm baffled here. I modeled the translate after withStyles and kept running into a wall. Finally I created this test repo to isolate and still the same problem.

Thoughts?

[rosskevin]

I just simplified the case, still same problem as soon as files are split. I cannot spot the problem.

[rosskevin]

Even stranger, I used/exported the Test1 from allInOne.js, just to see if it would work in index.js, and it does.

import ClassTest from './ClassTest'
import Test1FromAllInOne from './allInOne'

const Main = (props: {}) => {
  return (
    <div>
      <ClassTest /> /* fails */
      <Test1FromAllInOne />  /* works */
    </div>
  )
}

[rosskevin]

I updated the case further to see if I could use the translate HOC from allInOne.js, and I cannot.

So the common case appears to be that I cannot use a HOC exported from a file. This makes no sense to me as we aren't having the same problem in material-ui.

[rosskevin]

It appears that I can use the HOC from a separate file, but I have to assemble and use the final component in the same place.

import * as React from 'react';
import ClassTest from './ClassTest'
import ClassTestAIOOtherFile from './ClassTestAIOOtherFile'
import {Test1AIO, ClassTestAIO} from './allInOne'
import translateAIO from './allInOne'

const ClassTestAIOLocal = translateAIO()(ClassTestAIO)

class Main extends React.Component<{}> {
  render () {
    return (
      <div>
        <ClassTest /> /* fails - Component, HOC, and usage in separate files*/
        <Test1AIO /> /* works - component created in same file as HOC */

        /* additional attempts to figure it out */
        <ClassTestAIOLocal /> /* works - use same working components from Test1AIO but assemble here */
        <ClassTestAIOOtherFile /> /* fails - same as ClassTestAIOLocal but assembled in different file*/
      </div>
    )
  }
}

[rosskevin]

I've determined that this is failing with flow docs HOC example themselves

https://github.com/rosskevin/test-react-flow-types/tree/flow-docs-inject

[rsolomon]

I don't have any more insight, but I've observed similar issues when exporting a generic type modifier that uses $ObjMap.

I see a handful of open issues talking about issues using imported types, but they all seem to reference types being implicitly cast to any on import (errors being swallowed, instead of extra errors).

[rosskevin]

I have created a flow issue, I don't think this is isolated to react-flow-types.

It could be environmental to the project, or it could be a problem with flow itself.

facebook/flow#5382

[rosskevin]

@rsolomon - the strangest thing is that we have this working in material-ui, and I can't get anything to work otherwise. The mere fact that I cannot get the flow docs HOC to work tells me I'm either really doing something wrong or there is a serious regression in flow.

[AriaMinaei]

This is off-topic, but FWIW, I've given up on flow. I've found myself spending way too much time wrestling with the type system, making sense of the cryptic errors, and having to do all of this every few days because I've either hit an edge case or a new version of flow has broken something.

Even though I haven't really measured how much time I spend on these issues precisely, I'm convinced that it's been a net loss of productivity for me.

I've written about it before on HN:

I advocated flow for two years, and I still find it interesting as a typesystem. But what finally led me to give up was the core team's lack of community engagement.

It's very difficult get the team's attention to a bug or a question. As a result, they fail to see the common pain points of actual users.

Typing higher order components is one common pain point that still doesn't have a clear solution. So, unless you're avoiding HOCs altogether, you can't really benefit from type annotations in your react codebase (you'll have too many implicit anys).

You'll find more of these common use cases that flow doesn't optimise for. They're all over the issues section. Unfortunately, issues on Github generally don't get much attention from the team either, so I'm guessing users sometimes give up on reporting them. This has happened to me quite a few times. I didn't report some bugs because putting together a reduced test case takes time, and that time would be wasted if your issue is not gonna be paid attention to.

What makes matters worse, is that there is no public roadmap. You don't know what the team's priorities are. You don't know when the bugs that affect your work are gonna get fixed, or some feature you need is gonna get implemented. You don't even know if it's on the radar.

Of course, the Flow team is under no obligation to do any of that. They have no obligation to fix bugs for us or publish a roadmap. I'm already grateful that they've given us access to their work and without charging money. However, they do have the responsibility to communicate what their priorities are. If they're positioning Flow as an alternative to TypeScript, which is a well-supported, community-oriented project, then they should state clearly that Flow simply isn't. Call it a research project, or a project focused on a single company's use cases. Don't ask people to bet their own projects on it, when they clearly shouldn't. It'll be a big loss of productivity for them down the line, and your messaging is partly responsible for that.

I'll happily keep reviewing and merging PRs on this repo, but personally, I've lost interest in flow.

[rosskevin]

@AriaMinaei did you end up switching to Typescript? I think I may be where you where when you abandoned, but I still want to continue with some kind of static analysis.

I have spent days keeping flow definitions up to date, changing large libraries and finding a way to make them work.

At this point, with this particular issue, I'm stuck. I've got deadlines and I cannot just sit still until someone says "wow, that's a huge bug". Further, I don't know OCAML and I don't have time to be maintainer on yet another project, so I've got to make some decisions this morning. It's really disheartening to put so much in the direction of Flow only to think about abandoning it.

[rosskevin]

We have finished some research and are going to give Typescript a shot. I need to move forward.

[AriaMinaei]

@rosskevin I've had the same problem that you described. I'm slowly moving to TS, but I'll hold off on recommending it to pure JS, at least for a while. OTOH, I'm advising against flow for new projects.

[rsolomon]

FWIW, I've found that the best approach to Flow is to do things "the flow way." Sometimes that means having to forego standards to appease the sometimes admittedly limited type checking system. This means doing stuff like handling defaultProps in unconventional ways, or adding extra null checks or invariants around variables you know will never be null anyway.

Unfortunately this isn't a great option for open source projects, particularly because chances are high that a high number of your consumers don't care about Flow in the first place.

With enough push back, Facebook might put more effort into community support for Flow. It took a while, but Immutable.js was in the same boat for nearly a year (relevant issues immutable-js/immutable-js#1215 and immutable-js/immutable-js#1295 ).