[eysquared]

I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target.

You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.

[danabramov]

To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN commit) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something.

The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don’t really see a way around it for an actively developed library--which might be your point.

Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to “follow” it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.

[eysquared]

I love that development model for internal platforms, but it sounds like you are isolating yourself from the pain points that your customers often face.

My current company casts a weary eye at third party software so the import process is slow and involved. This means we only take major versions, and usually not very quickly. When those versions then introduce regressions in our own products and in dependent libraries it only serves to strengthen the voices calling to ditch the external solution entirely. It'd be a different story if a major version seemed to be of consistent quality to squat on for a while, but each new version brings its own challenges.

To be clear this is all involved in life as a dev in a large software company. For my own personal use I'd rather see RN move as fast as possible. I'm fighting the good fight to keep up (and increase) adoption at work so I just hope that FB and the RN team keeps these things in mind.

Thanks for the additional insight here.

[guelo]

Wow thanks, that explains a lot. So Facebook basically treats RN as an internal library, a single commit can change the framework API and the implementation at the same time so the constant API churn is not a problem.

[danabramov]

I'm talking about mostly mechanical changes (think find-and-replace or slightly more involved). Those are easier to do because they can be done on both RN and products at once.

This doesn't work for any larger changes because nobody is able to rewrite a ton of files by hand just to change some API. So this is why we can't make big changes to the API without a gradual adoption strategy, even internally.

[ascorbic]

That's interesting. Do you think there are situations where it would be beneficial for third parties to use RN from master rather than waiting for releases?

[danabramov]

If you have very good integration tests, sure you can try.

[philipwhiuk]

Couldn't agree more - AirBnB were already saying upgrading is a pain and this sounds like it'll be substantial.

I hope RN is going to stop relying on beta code for releases too.