(Подождите ... они вообще нам нужны?)

@ TripCase значительную часть нашей текущей работы составляют плагины Cordova. Эти плагины используются для связи с собственной структурой для выполнения операций и передачи результатов на сторону JS. При миграции React-Native много времени было потрачено на то, чтобы проанализировать, как эти плагины Cordova будут играть в новой экосистеме. Во-первых, мы думали, что нам придется либо найти способ полностью перенести плагины, либо полностью избавиться от них и беспокоиться о том, чтобы переписать их заново. Но когда мы фактически начали оценивать все плагины, мы сделали некоторые интересные выводы / выводы.

Из всех плагинов:

Approximately 70% plugins found their replacements either in React Native as in built option or as an open source library already out there. (which seemed ok since we didn't have to overwhelm ourselves with the fact that we had to rewrite all of the plugins at the very beginning of migration)
About 15% were no longer needed since they were essentially the backbone plugin of Cordova itself.
The remaining 15% plugins were a concern because:
- They were plugins specific to TripCase.
- Even though its React counterpart is available, its considered unsafe to replace the plugin right away because of additional functionality it offered.

Это означало, что мы оставляем оставшиеся 15% плагинов как есть на данный момент, находим способы общаться с ними и извлекать результаты, пока мы не переписываем их в лучшую сторону в будущем. После долгих мозговых штурмов мы пришли к двум возможным решениям.

  1. Найдите библиотеку, которая поможет связать Cordova с React Native.
  2. Возьмите только собственные файлы из плагина Cordova → создайте мост реакции на собственные файлы и настройте ответ.

Первый показался мне самым идеальным. Фактически, мы даже нашли библиотеку, которая предлагала именно это!

Https://github.com/axemclion/react-native-cordova-plugin.

Пока… мы не заметили, что он поддерживает только Android! Обескураженные этим фактом, мы отказались от этого варианта и рассмотрели вариант 2. Как бы сложно это ни звучало, все было не так уж плохо, когда мы действительно начали создавать прототип этой оболочки. Вот суть того, чего мы пытались достичь.

Коммуникатор JS фактически берет параметры из компонента. Параметры включают → Класс подключаемого модуля для вызова, метод ввода и данные (если есть), которые необходимо отправить в подключаемый модуль.

Чтобы предоставить модуль из нативного кода в JS, для реакции требуется, чтобы модуль был заключен в оболочку с помощью RCT_EXPORT_MODULE (); А чтобы раскрыть метод, мы явно заключаем его в оболочку RCT_EXPORT_METHOD. Мост на родной стороне выглядел примерно так. (PS: все крайние случаи не рассматриваются, так как это было сделано только для прототипа концепции моста для нескольких плагинов).

Это гарантирует, что указанное имя метода будет вызвано и переданы аргументы. sendPluginResultSuccess и sendPluginResultCancelled - это настроенные наблюдатели, которые прослушивают вызовы из собственного кода подключаемого модуля. В существующих плагинах Cordova мы заменили

pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK
                                 messageAsString:@”Success”];
[self.commandDelegate sendPluginResult:pluginResult
                            callbackId:callbackID];

примерно так:

[[NSNotificationCenter defaultCenter] 
postNotificationName: @”sendPluginResultSuccess” object: self];

Таким образом, мы смогли сохранить базовую функциональность как есть и изменить только код подтверждения между нативной стороной и стороной JS.

Теперь это не кажется таким уж плохим, не так ли? Не стесняйтесь размещать свои вопросы / мнения / предложения :)