Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intl Support #23

Open
danilobuerger opened this issue Jul 12, 2019 · 170 comments
Open

Intl Support #23

danilobuerger opened this issue Jul 12, 2019 · 170 comments
Labels
enhancement

Comments

@danilobuerger
Copy link

@danilobuerger danilobuerger commented Jul 12, 2019

In https://github.com/facebook/hermes/blob/master/doc/Features.md Intl is listed as Excluded From Support. With

Hermes plans to target ECMAScript 2015 (ES6), with some carefully considered exceptions.

What are those considerations regarding Intl? (If its about size, why not have a variant like jsc does?)
How should i18n look like with Hermes?

@fbartho
Copy link

@fbartho fbartho commented Jul 12, 2019

Intl is super important for us, and unfortunately, it's a blocker for my team. The Polyfills we tried before switching to jsc-intl weren't complete (they allowed compilation/basic testing, but didn't work in actual localized environments).

Is there a plan for when Intl might be discussed again for the Hermes Engine?

@dulinriley
Copy link
Contributor

@dulinriley dulinriley commented Jul 13, 2019

It will help us prioritize work on Intl if we know the following things:

  • Its main use cases (most popular function it has) to the RN community
  • Any important libraries that depend on it
  • What alternatives exist (is there a JS-only way to implement it?)

I don't remember the exact conversation we had about Intl, but I think it was related to ICU's binary size, and that it is not part of the normal EcmaScript JS spec.

@avp or @ridiculousfish have more context on this

@danilobuerger
Copy link
Author

@danilobuerger danilobuerger commented Jul 15, 2019

Its main use cases (most popular function it has) to the RN community

Enabling I18n for apps regarding:

  • Date / Time Formats
  • Relative Time Formats
  • List Formats
  • Number (also Currency) Formats
  • Plural Rules

Any important libraries that depend on it

https://github.com/formatjs/react-intl (> 10K Stars)
https://github.com/moment/luxon (> 8K Stars)

What alternatives exist (is there a JS-only way to implement it?)

As pointed out by @fbartho, polyfilling doesn't work properly. Every other solution is incomplete at least regarding locale rules around the world.

but I think it was related to ICU's binary size

If it is just about binary size, it could be done like JSC: a variant with Intl.
See https://github.com/react-native-community/jsc-android-buildscripts/#international-variant

and that it is not part of the normal EcmaScript JS spec

However, lots of functions that are part of the ECMAScript 2015, are dependent on Intl to function "properly", or at least need a locale aware implementation anyway. For example:

20.3.4.39 Date.prototype.toLocaleString ( [ reserved1 [ , reserved2 ] ] )
An ECMAScript implementation that includes the ECMA-402 Internationalization API must implement the Date.prototype.toLocaleString method as specified in the ECMA-402 specification. If an ECMAScript implementation does not include the ECMA-402 API the following specification of the toLocaleString method is used.

This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment’s current locale.

@dulinriley dulinriley added the enhancement label Jul 15, 2019
@TheTimeWalker
Copy link

@TheTimeWalker TheTimeWalker commented Jul 16, 2019

One thing to add: Intl works perfectly out of box on iOS as it has to use its V8 (oops!) JavaScriptCore engine which already integrates this. So I find it strange why we're trying to back off from Intl support as this would just confuse RN developers with the iOS and Android feature gap.

@fbartho
Copy link

@fbartho fbartho commented Jul 16, 2019

That's a great point @TheTimeWalker -- this is a "platform compatibility issue" where iOS & Android's JavaScript engines differ. (Nit: iOS uses the JavaScriptCore engine rather than the V8 engine, but your point is the same).

I guess the key question is: What is this project's driving mandate with regards to differences between iOS & Android? -- Presumably the expectation is that there shouldn't be significant framework-level differences? Especially not in things that can't be polyfilled-well.

Unfortunately, the existing Polyfills in this case are insufficient. React-Native developers targeting more than one language will be stuck on jsc-intl unless this feature is provided by Hermes!

@gmaclennan
Copy link

@gmaclennan gmaclennan commented Jul 23, 2019

As @danilobuerger clearly states, there is no complete and reliable JS-only solution to this. For I18n apps Intl is needed. It adds to binary size, but as I understand it that's because I18n is so darn complicated with so many edge-cases.

@wyzzy
Copy link

@wyzzy wyzzy commented Jul 30, 2019

Strong +1 for including Intl support out-of-the-box in Hermes, having just encountered this limitation ourselves!

At the moment the lack of Intl support on Android RN is a major source of inconsistency in behaviour between iOS and Android. On iOS Intl 'just works' as expected, but not so on Android, where you're stuck trying to find some workable solution to restore parity in behaviour on the two platforms. On iOS, Number.prototype.toLocaleString() for formatting numbers and currency values all work as expected, as does Date.prototype.toLocaleString() for dates, and all the Intl API...

The lack of Intl support on Android's out-of-the-box JSC was one significant hurdle we encountered in enabling our iOS-first RN app for Android. As many folks have said, the pollyfills just don't work well enough and feel like an unsatisfactory hack.

For our investment app, date/time and currency formatting are the primary drivers, though relative time rules, plural rules, and list formats would all undeniably help offer a more polished user experience.

Needing to include a custom JSC build on Android is non-trivial and really shouldn't be necessary for such a fundamental piece of functionality!

If Hermes is worried about size, some RN config to optionally exclude Intl support for those (rare?) apps that don't need it might be a way forward. Surely these days most commercial quality apps need to reliably present localised time & date or numeric/currency values?

If Hermes did fully support Intl, switching from the existing JSC would be a no-brainer for us. On the other hand, no support means we would perhaps be better off with a JSC build that does support it?? Feels like a problem that Hermes needs an answer to, one way or the other.

I18n certainly is darn complicated, which is precisely why it's so important that the platform itself offers first-class support for Intl out of the box! Even on Android.

@learnyst

This comment has been minimized.

@jcurtis
Copy link

@jcurtis jcurtis commented Aug 13, 2019

Intl is a major concern for all the apps I have ever worked on. Today we're using react-intl which is one of the most popular React libraries for handling intl. As stated before, there are no polyfills that work properly on Android right now.

I'd be curious if someone could tell us what Facebook uses to handle intl in their React Native apps? Specifically for number and date formatting.

facebook-github-bot pushed a commit that referenced this issue Oct 30, 2019
Summary:
This is used by the generateReleaseBuildConfig, which is needed when
fbjni is included as a submodule.
Pull Request resolved: facebookincubator/fbjni#23

Test Plan:
`./gradlew generateReleaseBuildConfig`
(In PyTorch) `./gradlew assembleRelease`

Reviewed By: passy

Differential Revision: D18226540

Pulled By: dreiss

fbshipit-source-id: c4ece2d1d8e7cbb095bc6991bbad53393e6f6ecb
@gpawlik
Copy link

@gpawlik gpawlik commented Dec 12, 2019

@dulinriley is there any more information that you need in order to prioritise this issue?

@feruzm
Copy link

@feruzm feruzm commented Dec 22, 2019

Big thanks to this thread, Hermes is great but we need support for Intl which most fundamental part of any app.

@OtacilioN

This comment has been minimized.

@OtacilioN
Copy link

@OtacilioN OtacilioN commented Jan 2, 2020

Hey folks,

Is that any workaround suggested for Number.prototype.toLocaleString() while they don't implement Intl ?

We broke our minds for some weeks with this bug because when we were using the debug mode in React Native, the Number.prototype.toLocaleString() works, I think because it uses my browser engine to run JavaScript, but as soon we assemble the app or turnOff the debug mode, Number.prototype.toLocaleString() starts to no work.

@fbartho
Copy link

@fbartho fbartho commented Jan 2, 2020

@OtacilioN -- On my team we're still using org.webkit:android-jsc-intl:r245459 until Hermes supports Intl (we would love to use Hermes for Android Performance reasons!!) Not to give you useless advice, but that's what I recommend.

And I ran into exactly the same debug-time issues with some other features including Proxy (also missing in Hermes, #33), before that was updated to be available on android-jsc. I feel your pain!

@OtacilioN

This comment has been minimized.

@mars-lan

This comment has been minimized.

@patrickkempff
Copy link

@patrickkempff patrickkempff commented Jan 8, 2020

How does facebook handle Intl in their apps when using Hermes?

@thinklinux

This comment has been minimized.

@tmikov
Copy link
Contributor

@tmikov tmikov commented Jan 9, 2020

Sorry about the delayed response here. Internally at Facebook we use fbt, with its own specific translation assets handling, and translation dictionary shipped with the app binary. fbt was open sourced a while back, and fortunately we have RN android variant in OSS now.

See:
https://github.com/facebookincubator/fbt
https://github.com/facebookincubator/fbt/tree/master/packages/fbt-rn-android-native
https://github.com/facebookincubator/fbt/tree/rn-demo-app

The published version currently builds for Android but AFAIK there is nothing preventing porting to iOS.

On the subject of Intl support: we would like to have it in Hermes, but it isn't our top priority, since, as described above, we don't use it internally. We welcome help from the community in implementing it.

@TheSavior
Copy link
Member

@TheSavior TheSavior commented Mar 27, 2020

EDIT: I found that Chrome Status shares data publicly on the usage of these APIs. I have gathered and ordered that data for the Intl APIs in this comment.

Additional anecdotal data is probably not as helpful now.


We are revisiting Intl support on Hermes and need your help figuring out which functions to prioritize. There are a ton of Intl APIs and I'd bet that only a handful of them are the most critical functions blocking Hermes adoption.

Please help us understand the particular function calls that are blocking your ability to use Hermes. For example, I've seen Number.prototype.toLocaleString() mentioned twice in this thread. That's the kind of specific example I'm looking for. "Relative Time Formats" is too vague. I'm sure there are many more functions that would be really nice to have but aren't as critical. Please mention them, but separately so I can track that.

Intl functions blocking usage of Hermes:

  • Number.prototype.toLocaleString()
  • Date.prototype.toLocaleString
  • Date.prototype.toLocaleTimeString
  • Intl.DateTimeFormat().resolvedOptions
  • Intl.DateTimeFormat().format() (specific options)
  • Intl.NumberFormat().format() (specific options)
  • Intl.RelativeTimeFormat().format()
  • String.prototype.localeCompare

Also, I saw a mention of the react-intl project. Can someone go through that and identify what Intl functions it uses and share those here?

Thanks!

@fbartho
Copy link

@fbartho fbartho commented Mar 27, 2020

I'm not entirely sure how to search react-intl for "particular function calls" that need to be supported. I'm trying to join their slack to figure that out.

In addition to react-intl, a super popular library is MomentJS -- https://momentjs.com & its sub library moment-timezone https://momentjs.com/timezone/

Moment has a CI testing various browsers/environments, so maybe you can add hermes to that list, and then get an enumeration of the methods that are missing / fail tests?

@dlebedynskyi
Copy link

@dlebedynskyi dlebedynskyi commented Mar 27, 2020

@TheSavior
I believe we are specifically interested in DateTime and TimeZone related ones such as

  • Date.prototype.toLocaleString
  • Date.prototype.toLocaleTimeString
  • Intl.DateTimeFormat().resolvedOptions
  • rest of timezone related things

For react-intl it is probably better to start with intl-messageformat as it is most used one.

@fbartho
I believe moment is not actually using Intl.

@fbartho
Copy link

@fbartho fbartho commented Mar 27, 2020

Our codebase also directly uses

@janicduplessis
Copy link

@janicduplessis janicduplessis commented Mar 27, 2020

I'm currently using the following polyfills for Hermes:

I'm using https://lingui.js.org/ as a higher level abstraction over intl apis.

I don't have anything blocking usage of hermes since it works fine with these polyfills. First thing would be to try and remove usage of the intl polyfill, this one actually implements a lot of apis, the list is available here https://github.com/andyearnshaw/Intl.js#implemented.

Here are some Intl apis I use either directly or through lingui-js:

  • Intl.NumberFormat for currency formatting.
  • Intl.DateTimeFormat for date formatting.
  • Intl.RelativeTimeFormat for relative date formatting (x days ago).

@TheSavior
Copy link
Member

@TheSavior TheSavior commented Mar 27, 2020

@dlebedynskyi thanks, from my quick searching it looks like IntlMessageFormat isn't part of a finalized spec. Am I looking in the wrong place?

@TheSavior
Copy link
Member

@TheSavior TheSavior commented Mar 27, 2020

@janicduplessis, it looks like the Intl APIs you list are a collection of multiple functions. Do you know which functions in those APIs you use? The more specific the better here :)

@andreialecu
Copy link

@andreialecu andreialecu commented Dec 29, 2021

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

This allowed us to finally drop the polyfills and there's an amazing performance boost on Android as a result in our app. 🎊

@mattijsf
Copy link

@mattijsf mattijsf commented Dec 29, 2021

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

This allowed us to finally drop the polyfills and there's an amazing performance boost on Android as a result in our app. 🎊

Until you need timezone conversion support though 👀

@andreialecu
Copy link

@andreialecu andreialecu commented Dec 29, 2021

Until you need timezone conversion support though 👀

The commit I linked specifically fixes the bug in timezone conversion support that was present in 0.9.0.

@mattijsf
Copy link

@mattijsf mattijsf commented Dec 30, 2021

Until you need timezone conversion support though 👀

The commit I linked specifically fixes the bug in timezone conversion support that was present in 0.9.0.

Thanks I was too quick with my comment sorry. Unfortunately polyfills are still necessary on iOS to be able to do the timezone conversion (when using Hermes). I read above that this is being worked on 🤞

@billnbell
Copy link

@billnbell billnbell commented Jan 24, 2022

Question with hermes in v0.67.1 react-native enabled do I need this?

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}

@cristianoccazinsp
Copy link

@cristianoccazinsp cristianoccazinsp commented Feb 1, 2022

What is the progress on this? INTL support is the only release blocker for us to move to Hermes on iOS. The polyfills are way too slow and incorrect.

@tranducduong1994
Copy link

@tranducduong1994 tranducduong1994 commented Mar 10, 2022

Any update on IOS Intl support?

@pke
Copy link

@pke pke commented Mar 11, 2022

@andreialecu

Hermes 0.10.0 finally fixes all outstanding Android Intl issues. (ref: 9238467)

I've been able to use yarn resolutions to force Hermes to version 0.10.0 even on RN 0.66 via:

  "resolutions": {
    "hermes-engine": "0.10.0"
  }

Does this make this obsolete?

 if (typeof Intl === "undefined") {
    require("intl")
    require("intl/locale-data/jsonp/nl") // may be different for you
  }

@andreialecu
Copy link

@andreialecu andreialecu commented Mar 11, 2022

@pke: Most polyfills should no longer be required with the updated Hermes. So yes, those two should be obsolete.

You should check however if things work properly after removing them. I think RelativeTimeFormat was not implemented by Hermes yet, for example.

@pke
Copy link

@pke pke commented Mar 11, 2022

@andreialecu how do I know which Hermes engine is currently bundled with my RN project?
And is there a List of not yet implemented functions like RelativeTimeFormat (which we do not use atm)?

@mrousavy
Copy link
Contributor

@mrousavy mrousavy commented Mar 11, 2022

how do I know which Hermes engine is currently bundled with my RN project?

You can check yarn.lock and search for hermes-engine.

@francois-pasquier
Copy link

@francois-pasquier francois-pasquier commented Mar 24, 2022

is iOS still needing polyfills with latest hermes?

@nandorojo
Copy link

@nandorojo nandorojo commented Mar 28, 2022

how do I know which Hermes engine is currently bundled with my RN project?

You can check yarn.lock and search for hermes-engine.

yarn why hermes-engine

@neildhar
Copy link
Contributor

@neildhar neildhar commented Mar 28, 2022

is iOS still needing polyfills with latest hermes?

As of now, yes, although we are actively working on Intl support. Support for the upper/lowercase conversion functions, getCanonicalLocales, and Collator has already been merged in trunk.

@zhiqingchen
Copy link

@zhiqingchen zhiqingchen commented Mar 30, 2022

Same issue, Using
new Date().toLocaleTimeString()

will cause

Error: RangeError: java.lang.ClassNotFoundException: Didn't find class "com.facebook.hermes.intl.DateTimeFormat"

@gavinaboulhosn
Copy link

@gavinaboulhosn gavinaboulhosn commented Apr 21, 2022

Same issue, Using new Date().toLocaleTimeString()

will cause

Error: RangeError: java.lang.ClassNotFoundException: Didn't find class "com.facebook.hermes.intl.DateTimeFormat"

@zhiqingchen Make sure you're including the Hermes android artifacts on the classpath. If you're using Proguard, you may need to create a rule to avoid stripping Hermes classes. e.g. -keep class com.facebook.hermes.** { *; }

@billnbell
Copy link

@billnbell billnbell commented Apr 22, 2022

Question with hermes in v0.67.1 react-native enabled do I need this?

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}

OK, with 0.68.1 which of these can I drop?

@mattijsf
Copy link

@mattijsf mattijsf commented Apr 22, 2022

@billnbell For me it's also unclear to what extent Intl is supported on both platforms. I would love to see some official support matrix of Hermes (sub)features for each platform per Hermes version.

@Jackman3005
Copy link

@Jackman3005 Jackman3005 commented May 24, 2022

@mattijsf They have a Intl APIs page that covers what is supported/not yet supported and limitations of different versions of Android. But I believe there is still no iOS support for Intl in hermes.

I'm using a time zone library for displaying a list of time zones and it has a reasonable usage of Intl that is currently causing zero timezones to be retrieved in iOS due to the lack of support for Intl. Looks like I'll need to polyfill for iOS until this is supported with hermes. I will try something along the lines of what @billnbell has done.

Thanks for all the hard work on Hermes so far, you folks rock. I'm looking forward to when (soon?) Intl support is solid for both platforms.

@zbraniecki
Copy link

@zbraniecki zbraniecki commented Jun 13, 2022

hi all. I'm one of the founders of the ICU4X project which is a Rust implementation of ICU targeting many programming environments and aiming for the ECMA-402 scope.

One of the interesting features of ICU4X is that one can pull small modules that provide necessary components without paying for the whole monolithic codebase, and compile those components to WASM or JS.

We are planning to release 1.0 quite soon and I'm wondering if Hermes would be interested in evaluating ICU4X for your needs.

@jkester1986
Copy link

@jkester1986 jkester1986 commented Jun 14, 2022

We just turned off Hermes in our iOS app after recently turning it on due to discovering lack of intl support for dates/times. Do we have any ETA on when this will be supported on the iOS side?

@jpporto
Copy link
Contributor

@jpporto jpporto commented Jun 15, 2022

Hi @jkester1986,

The Hermes iOS Intl support (for date and time) is already implemented, but some wiring is needed on RN to surface it. We expect the next RN version (i.e., 0.70) to have that plumbing done, and full feature parity with Hermes on Android for RN 0.71

@billnbell
Copy link

@billnbell billnbell commented Jun 15, 2022

Hi @jpporto - what is status os IOS support for Intl ?

@jpporto
Copy link
Contributor

@jpporto jpporto commented Jun 15, 2022

Hi @billnbell,

Hermes' iOS Intl support is defined here. It seems currently, Number, DateTime, and Collator are implemented. Other missing features are being actively implemented.

@datanaman
Copy link

@datanaman datanaman commented Jun 23, 2022

Hi Team , we are facing the issue only on IOS after enabling Hermes :
Issue :
ReferenceError: Property 'Intl' doesn't exist, js engine: hermes
ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). A frequent cause of the error is that the application entry file path is incorrect.

Version : "react-native": "0.68.2"

image

Tried the below workaround in our index.ts - but doesn't seem to work.

import { AppRegistry, Platform } from 'react-native';
// eslint-disable-next-line no-undef
const usingHermes = typeof HermesInternal === 'object' && HermesInternal !== null;
if (usingHermes && Platform.OS === 'ios') {
// Polyfills required to use Intl with Hermes engine
require('@formatjs/intl-getcanonicallocales/polyfill');
require('@formatjs/intl-locale/polyfill');
require('@formatjs/intl-pluralrules/polyfill');
require('@formatjs/intl-pluralrules/locale-data/en');
require('@formatjs/intl-numberformat/polyfill');
require('@formatjs/intl-numberformat/locale-data/en');
require('@formatjs/intl-datetimeformat/polyfill');
require('@formatjs/intl-datetimeformat/locale-data/en');
require('@formatjs/intl-datetimeformat/add-golden-tz');

//require('intl'); // import intl object
}

import App from './src/App';
import { name as appName } from './app.json';

AppRegistry.registerComponent(appName, () => App);

Any other Workaround or something which we are missing ?

@billnbell
Copy link

@billnbell billnbell commented Jun 23, 2022

You are not putting it in right spot. Put in index.js:

/* eslint-disable no-unused-expressions */
/* eslint-disable @typescript-eslint/no-var-requires */
/* eslint-disable global-require */
import React from 'react';
import { AppRegistry, Platform } from 'react-native';

import { expo } from './app.json';
import App from './src/App';
import AppFake from './src/AppFake';
import { configureCalendarLocale } from './src/components/member/explore/property-screen/dateHelpers';
import { setBackgroundMessageHandler } from './src/utils/notificationHandler';

const { name: appName } = expo;

if (global.HermesInternal) {
  if (Platform.OS === 'ios') {
    // Polyfills required to use Intl with Hermes engine
    require('@formatjs/intl-getcanonicallocales/polyfill').default;
    require('@formatjs/intl-locale/polyfill').default;
    require('@formatjs/intl-pluralrules/polyfill').default;
    require('@formatjs/intl-pluralrules/locale-data/en').default;
    require('@formatjs/intl-numberformat/polyfill').default;
    require('@formatjs/intl-numberformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/polyfill').default;
    require('@formatjs/intl-datetimeformat/locale-data/en').default;
    require('@formatjs/intl-datetimeformat/add-all-tz').default;
  } else {
    require('@formatjs/intl-getcanonicallocales/polyfill');
    require('@formatjs/intl-locale/polyfill');
    require('@formatjs/intl-datetimeformat/polyfill');
    require('@formatjs/intl-datetimeformat/locale-data/en');
    require('@formatjs/intl-datetimeformat/add-all-tz');
  }
}
configureCalendarLocale();
try {
  setBackgroundMessageHandler();
} catch (err) {
  console.log('index.js setBackgroundMessageHandler', err);
}
const HeadlessCheck = (props) => {
  // eslint-disable-next-line react/prop-types
  const { isHeadless } = props;
  if (Platform.OS === 'ios' && isHeadless) {
    return <AppFake />;
  }
  // eslint-disable-next-line react/jsx-props-no-spreading
  return <App {...props} />;
};

AppRegistry.registerComponent(appName, () => HeadlessCheck);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement
Projects
None yet
Development

No branches or pull requests