react-native-tvos / react-native-tvos

React Native repo with additions for Apple TV and Android TV support. https://douglowder.github.io/react-native-apple-tv/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Why tvOS is a fork and not a module?

brodybits opened this issue · comments

updated:

Summary: see title which was updated several times, by multiple people, and is now a question.

Resolution: see below - agreed on my part

Original rationale:

I did not realize until after I merged brodybits/create-react-native-module#91 that tvOS was actually moved into its own package separate from the core react-native package. I then raised facebook/react-native-website#1250 to add this to the documents.

original idea now withdrawn on my part:

But I am now wondering if we could find a way to improve on a couple things.

It seems to me that this repo is a full-blown fork of react-native. I think it would be been nicer if react-native-tvos would use react-native as a dependency, and reuse as much as possible, in a similar fashion to react-native-windows, react-native-dom, and react-native-turbolinks.

I can think of the following reasons:

  • support combination with other platforms such as Windows, DOM, and possibly macOS more cleanly
  • applications and native modules can always use react-native from the standard place
  • enable applications and native modules to use react-native patch updates

(I would also like to see a similar idea applied for react-native-macos.)

more details withdrawn on my part

I think this would be a breaking change that should target an upcoming react-native release, perhaps 0.61.

Unfortunately I don't have so much time to look into this idea right now, hope I can take a look someday.

an old update now withdrawn on my part P.S. I now think that tvOS should be built from its own `tvos` subdirectory, see my response below.

The key difference between tvOS support in React Native, versus other out of tree platforms like Windows and web, is that tvOS shares almost all its native code with iOS. The tvOS-specific native code can be generally divided into these types:

  • Preprocessor directives in common Objective-C files to stub out code that won't compile on tvOS
  • Xcode project changes (or podspec additions) to exclude iOS-only features (like sliders and switches) from tvOS targets
  • tvOS-only files to implement basic functionality (RCTTVView, RCTTVEventHandler, etc.)
  • tvOS-only files to implement special features needed for some apps (RCTTVFocusGuideView, etc.)

Ideally, the core repo would have all the first three types of changes, and react-native-tvos could be a module that adds the special TV add-on features. However, the core team does not want to support tvOS there any more, and can't guarantee that the core repo will not be broken on tvOS at any given time.

(When I originally merged the tvOS changes, I added tvOS testing to the CI scripts run in open source; however, at the time, FB had a process that routinely merged changes only after running their own internal CI that didn't include tvOS.)

I could provide a tvOS module that would apply a giant patch to all the iOS files in core, but that would be a VERY large patch, probably very brittle to small changes in core, etc., etc.

So the best option I can see at the moment is running a fork, where I release versions based on specific core releases. The release notes for each tvOS version show exactly the commits applied on top of the base core release.

The key difference between tvOS support in React Native, versus other out of tree platforms like Windows and web, is that tvOS shares almost all its native code with iOS.
[...]

Understood and agreed.

I still think it should be possible to have a separate tvos platform directory with a generated project that builds with most of the modules and libraries from node_modules/react-native/React/Base, node_modules/react-native/React/Views, node_modules/react-native/React/Modules, and node_modules/react-native/Libraries. The generated project would then use a limited number of tvOS-specific modules that import from iOS modules in order to give any tvOS-specific support needed. Much cleaner and probably less error-prone, I think.

The idea that a project should have a separate tvos directory for the generated tvOS project would be consistent with an idea to support react-native run-tvos from: https://youtu.be/zrYiQr6CBg8?t=604

I hope I can give this idea a try someday. Unfortunately I cannot make any promises right now.

When I use this fork the app builds and compiles but when I try npm install in changes I get this error :
No matching version found for react-native@0.60.4-6
In most cases you or one of your dependencies are requesting
a package version that doesn't exist.

Why?

When I use this fork the app builds and compiles but when I try npm install in changes I get this error :
No matching version found for react-native@0.60.4-6
[...]

I recommend you raise a new issue with a minimal reproduction: https://stackoverflow.com/help/minimal-reproducible-example

I am not a maintainer of this module and it is not such a high priority for me to contribute any active support right now.

I just tested this with a new app generated with react-native init.

I think the problem you are seeing is in the package.json alias dependency for react-native:

  "react-native": "npm:react-native-tvos"

This is not supported by npm install, but is supported by yarn. I recommend using yarn over npm anyway -- it's generally faster.

If you are still seeing this problem, then (as @brodybits suggested above) please create a new issue with a minimal set of repro steps.

From discussion in #14, I would now conclude that this project is really a fork to support one or more TV operating systems, as opposed to a truly separate "out-of-tree" module.

This would be very similar to the way that Expo has its own expo/react-native fork, which it uses to release the various Expo SDK versions.

Now downvoting and hiding my own idea in #11 (comment) as resolved.

Since this is a fork of react-native, then the release schedule for this repo will practically not be the same as the parent repo, so in a scenario where I will need to upgrade ios/android mobile apps to latest react-native versions, I will have to wait for tvOS to make a release. Right?

@keshavkaul you are correct, you will have to wait until this repo supports the latest RN core version. That would likely be a problem even if this were an add-on module instead of a fork. There have been quite a few changes in recent versions of RN core that broke tvOS....

Thanks! I'm now leaning towards having a monorepo project setup either with lerna or yarn workspaces. We plan on supporting mobile, tv, web, firetv, Xbox, so having each platform be a separate package with their own dependencies but re using common code seems ideally feasible. Any thoughts you'd like to share about advantages or disadvantages of monorepos will greatly help me out. Thanks again for the TV repo! I will surely be investing time to contribute here.

@dlowder-salesforce great effort trying to keep react-native tvos alive 🥇

I wondered same when I tried to integrate this into
https://github.com/pavjacko/renative

I managed to get some of initial issues out of the way however there are some outstanding issues to tackle (which forced me to stick with RN + some overrides at least for now):

  • ios-only dependencies
    biggest problem I faced was with some of the fundamentals still cross-wired with ios implementations

This made it very difficult to use it alongside standard react-native as renative has to support multiplatform monorepos

  • lack of native plugins
    even in renative I had to "hack" quite a few libraries to even compile for tvos and I managed to get few of them working but it's still a bit of a way. easied integration to existing RN project would make this more viable for plugin developers

  • bundler naming collisions
    this happens if you try to run tvos and standard RN under same project as there are duplicate classes present in node_modules

  • versioning, keeping up to date with RN
    I wonder what's the strategy of keeping this in sync with latest RN releases. as at the time of testing it was 1 major release (0.61 in RN) causing causing compatibility issues

  • focus issues
    even with this repo I has some issues with focusable elements. I managed to fix those but it was small enough to be able to retro fix directly in RN
    focus guides are helpful but it still not enough for more complex focus scenarios from the experience but with bit of tweaking definitely possible

@keshavkaul multi-platform RN monorepo is definitely possible
renative itself started as lerna project https://github.com/pavjacko/renative/tree/master/packages

I think if above obstacles would be solved it could definitely be viable alternative to current RN situation on tvos platform

@dlowder-salesforce I think most of the fundamentals are in RN and with good API (RN is moving towards smaller core anyway) tvos support could be achieved with smaller and more focused implementation as native extension and maybe with some overrides (at least that's how I managed to get it all somehow working)

Just thinking out loud

keep up the great work 👍

@pavjacko thanks for the excellent commentary -- sorry I didn't respond sooner, I was offline due to medical issues for a couple of weeks.

bundler naming collisions

In a monorepo, I would either use this package, or the RN core package, but not both. This repo is intended to work for iOS, tvOS, and Android, and just add tvOS fixes to what is already in core.

versioning, keeping up to date with RN

This is discussed in detail in #32

lack of native plugins

Third party support for RN tvOS is a problem. I've managed to get a number of them working. Most of the time it's just adding tvOS to the podspec, but sometimes actual code changes are required.

focus issues

I'd be interested to hear about the issues you encountered and your fixes. Did you submit fixes to RN core directly?

tvos support could be achieved with smaller and more focused implementation

Not sure what you mean by this, but if you have ideas that would lead to easier tvOS maintenance, I'd love to hear them :)