Всегда ведь будет какая-то конкретная модель хранения / изменения данных. Либо общеиспользуемые подходы redux/mobx/relay и тд, либо что-то свое. Но чтобы был смысл писать свое решение — оно должно решать какие-то проблемы. Видимо пока таких проблем нету.
Можно посмотреть с двух сторон:
1) Со стороны мобильной платформы
2) Со стороны проектов которые используют мобильную платформу
Со стороны мобильной платформы отказаться от redux и оставить react-native — просто. Мы от него почти не зависим и получается в нативном коде изменений не будет.
Со стороны проектов отказаться от redux и оставить react-native уже сложнее. Потребуется вносить изменения в js-код. Количество изменений зависит от того, на какой фреймворк/архитектуру мы переходим(mobx/relay/...).
Со стороны мобильной платформы выкинуть react native — это значит написать свою обертку над фреймворком JavaScriptCore, которая возьмет обязанности React native на себя. Т.е появится слой, который будет получать JSON из уровня JS-кода и что-то на его основе делать с нативным кодом. И наоборот — на основе событий нативного уровня будет отправлять JSON на уровень JS. На самом нативном коде будет минимум изменений.
Но при этом сам нативный код можно переиспользовать в проектах в которых нет React Native.
Со стороны проектов выкинуть react-native(но оставить react) — это в принципе тоже самое что и со стороны платформы, т.е нужно будет написать свой механизм взаимодействия JS <-> Objective-C. Но при этом проект продолжит работать в вебе, потеряем только мобильное приложение.
Presenter — это сущность в нативном коде. Да, весь viper-подход содержится только в нативной части. На уровне JS-кода разработка идет согласно архитектуре redux.
Т.е типичный компонент это:
1) один js-файл, в котором импортируется нативная UIView и объявляется React.Component, который возвращает эту вью в своем рендер методе.
2) ViewManager: RCTViewManager — синглтон, который создает UIView и передает параметры в presenter. Его использует React Native.
3) Presenter: NSObject
4) View: UIView
5) Interactor: NSObject
6) Иногда Wireframe: NSObject
Все кроме пункта 1 — это нативный код. Единственная часть которая зависит от React Native в нативном коде — это пункт 2
Компонент связывается с redux-стором посредством стандартных биндингов входящих в пакет react-redux, т.е используется Provider и connect.
Компонент — это чистая функция. При изменении стейта React обновляет virtual dom, если параметры компонента(т.е функции) изменились — React Native пробрасывает измененные параметры на нативный уровень(bridge level).
Bridge level конвертирует полученный JSON в нативные типы данных и вызывает соответствующие методы презентера. Презентер смотрит на то, что ему пришло и в каком состоянии он находится. И на основе этого обновляет UIView. UIView состояния не имеет и все свои события пробрасывает в презентер. От презентера опять попадаем в bridge level, React Native пробрасывает события из нативного уровня на уровень JS.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
1) Со стороны мобильной платформы
2) Со стороны проектов которые используют мобильную платформу
Со стороны мобильной платформы отказаться от redux и оставить react-native — просто. Мы от него почти не зависим и получается в нативном коде изменений не будет.
Со стороны проектов отказаться от redux и оставить react-native уже сложнее. Потребуется вносить изменения в js-код. Количество изменений зависит от того, на какой фреймворк/архитектуру мы переходим(mobx/relay/...).
Со стороны мобильной платформы выкинуть react native — это значит написать свою обертку над фреймворком JavaScriptCore, которая возьмет обязанности React native на себя. Т.е появится слой, который будет получать JSON из уровня JS-кода и что-то на его основе делать с нативным кодом. И наоборот — на основе событий нативного уровня будет отправлять JSON на уровень JS. На самом нативном коде будет минимум изменений.
Но при этом сам нативный код можно переиспользовать в проектах в которых нет React Native.
Со стороны проектов выкинуть react-native(но оставить react) — это в принципе тоже самое что и со стороны платформы, т.е нужно будет написать свой механизм взаимодействия JS <-> Objective-C. Но при этом проект продолжит работать в вебе, потеряем только мобильное приложение.
Т.е типичный компонент это:
1) один js-файл, в котором импортируется нативная UIView и объявляется React.Component, который возвращает эту вью в своем рендер методе.
2) ViewManager: RCTViewManager — синглтон, который создает UIView и передает параметры в presenter. Его использует React Native.
3) Presenter: NSObject
4) View: UIView
5) Interactor: NSObject
6) Иногда Wireframe: NSObject
Все кроме пункта 1 — это нативный код. Единственная часть которая зависит от React Native в нативном коде — это пункт 2
Компонент — это чистая функция. При изменении стейта React обновляет virtual dom, если параметры компонента(т.е функции) изменились — React Native пробрасывает измененные параметры на нативный уровень(bridge level).
Bridge level конвертирует полученный JSON в нативные типы данных и вызывает соответствующие методы презентера. Презентер смотрит на то, что ему пришло и в каком состоянии он находится. И на основе этого обновляет UIView. UIView состояния не имеет и все свои события пробрасывает в презентер. От презентера опять попадаем в bridge level, React Native пробрасывает события из нативного уровня на уровень JS.