[UIExplorer] App is broken: Attempted to assign readonly property. (ActivityIndicatorIOS.ios.js)

[bparadie]

I synced to commit 522fd33, cleaned UIExplorer and tried to run it on the simulator using iPhone 5 (8.3). Here is what I got:

[bparadie]

@vjeux I am still seeing this problem after syncing to the latest commit (e47cfb6).

[bparadie]

@vjeux In the debugger I am seeing that createReactNativeComponentClass for RCTView returns undefined:

var RCTView = createReactNativeComponentClass({
  validAttributes: ReactNativeViewAttributes.RCTView,
  uiViewClassName: 'RCTView',
});

On the stack I see var View = require('View'); (line 18) in ActivityIndicatorIOS.ios.js.

Then drilling further into createReactNativeComponentClass... This line seems to be the trouble maker:

  return ((Constructor: any): ReactClass);

That doesn't look like JS to me, not even ES6. Is this flow syntax? Shouldn't that be transformed?
If I execute that line in the debugger I'll get:

I am taking a wild guess here: Is it possible that you guys at FB use a more advanced flow version than the rest of the world? I believe expressions like (Constructor: any) should get transformed by your flow tool to proper JS - assuming you have the right flow version. Again, this is just a wild guess.

Just for clarity, my environment is: OSX 10.10.2, running XCode 6.3.1 and the simulator for iPhone 6 (ios 8.1).

flow version is:

/usr/local/bin/flow --version
Flow, a static type checker for JavaScript, version 0.12.0

Latest flow version is 0.12.0.

[bparadie]

@vjeux Ah, here is the puppy that messed everything up...
It's a recent commit for [Flow] Fix or suppress react-native github errors for Flow v0.12.0,
1acca01.

@gabelevi @sahrens Do I need a special flow version in order to use your 'fix'? I am using 0.12.0.

[bparadie]

@vjeux @gabelevi @sahrens @brentvatne Everything works great again after reverting back to return Constructor. I don't even see any flow errors with my 0.12.0 version.

Now, this journey brings up a few interesting points:

• react-native has a dependency to flow, which is supposed to be installed as a global tool.
• there is no version dependency check in place that would enforce flow updates (i.e. this react-native version requires that flow version)
• all react-native windows need to be closed after upgrading flow. But that's easy to forget and then you run into errors that don't look like flow problems at all.
• does flow allow global .flowconfig files? If so you have to anticipate that global .flowconfig settings might interfere with local .flowconfig settings.

This side note is probably more interesting to @avikchaudhuri, which I had the honor to work with when he was still at Adobe: I find flow's value proposition quite thin in light of having the option of just using Typescript. I've been using Typescript for over a year now and I don't really see a need for flow. I gave flow a try in one of my projects and it was just too slow and didn't find anything that Typescript wouldn't have flagged. I finally had enough and disabled flow altogether by adding these lines to .flowconfig:

# bparadie flow takes up two minutes.
.*/*.js

I am sure flow has improved a lot in the last months and is much faster and better, and I could probably narrow the search scope to a few folders I care about. But why going through the trouble of re-enabling flow? To make a fair offer, I could be persuaded to try flow again if I were presented, say, 3 examples where flow would find something suspicious, or questionable, that Typescript would not detect. So far it has been rather the other way around for me (Typescript found more than flow). I am not interested in flow enhancements that are essentially syntactic sugar improvements, along the lines of "you don't have to specify the type here, we'll figure that out". I don't mind spelling out the types. Besides: Typescript is pretty good at inferring types, too.

[satya164]

Closing this as this is an old issue and seems to be fixed. Let's reopen if you still have the issue.