Comments 33
Очень классная платформа, но хочется больше технических подробностей. Кстати, чем обусловлено то, что вы не приемлете fork-библиотеки?
Очень классная платформа, но хочется больше технических подробностей.
Спасибо! Мы только начали цикл статей — в дальнейшем будем раскрывать технические детали каждого конкретного направления / модуля платформы.
Кстати, чем обусловлено то, что вы не приемлете fork-библиотеки?
Мы начали разрабатывать на версии 0.33.0 (iOS), сейчас уже версия 0.41.0
Версии меняются очень быстро — и мы бы не хотели каждый раз вносить изменения в нашу «копию» библиотеки.
Как мы пытались показать в статье — мы стараемся не сильно зависеть от внутренностей ReactNative и используем только минимально необходимую часть для рендеринга компонентов и проброса вызовов из JS в obj-c.
А платформа всем доступна за плату или как там ещё? Или просто внутренней разработкой хвастаетесь? Хотелось бы подробно, про бекенд, фронтенд и особенно — поддержу приложения.
А платформа всем доступна за плату или как там ещё? Или просто внутренней разработкой хвастаетесь?
На текущий момент платформа развивается indoors и используется внутри продуктов банка, но некоторые модули уже скоро попадут в outsource :)
Уверен, что на эту тему будет отдельный анонс и пост.
Хотелось бы подробно, про бекенд, фронтенд и особенно — поддержу приложения.
Мы начинаем цикл статей и будем рассказывать конкретные детали различных аспектов. Спасибо за интерес!
Создавать свою архитектуру, компоненты и реализацию react native при наличии единственной мобильной платформы в виде iOS… Странно, по-моему. Ну, разве что вы джаваскриптеров уже устали бочками солить.
Если вам так не подходит ReactNative, почему вы не выбрали тот же NativeScript, в вашем случае?
1. Мы не говорим, что нам не подходит ReactNative. Именно он и подходит. Мы говорим, что мы хотим минимизировать риски, которые мы видим в использовании ReactNative.
2. Мы выбрали ReactNative, потому что он является естественным продолжением фреймворка React от того же разработчика. Кроме мобильной платформы есть на текущий момент и web-платформа, написанная на стеке TypeScript, React + Redux. Одной из важной задач мобильной платформы — это унификация API и компонентов с web-платформой, так чтобы можно было создать единую платформу для сборки мобильных и web приложений.
2. Мы выбрали ReactNative, потому что он является естественным продолжением фреймворка React от того же разработчика. Кроме мобильной платформы есть на текущий момент и web-платформа, написанная на стеке TypeScript, React + Redux. Одной из важной задач мобильной платформы — это унификация API и компонентов с web-платформой, так чтобы можно было создать единую платформу для сборки мобильных и web приложений.
И всё таки… Вы конструктор моб. приложений делаете?
Платформа — это многомодульная система.
Например, в неё входят:
— мобильная библиотека (которая встраивается в мобильные приложения)
— модуль платформу на backend'e
— различные шлюзы (из-за богатой внутренней инфраструктуры)
— инструменты DevOps
— методологии и инструменты тестирования
— средства для сбора мобильной аналитики и логов
и т.д.
Мобильная библиотека — это конструктор приложений в некотором роде, т.к. она основана на принципах разбиения всей функциональности на некоторые блоки — компоненты.
Компоненты бывают визуальными (кнопки, чекбоксы, прогресс-бар, загрузчики, карты и т.д.), из которых выстраивается интерфейс и не визуальными или сервисами (логирование, работа с сетью, удаленное управление и т.д.).
Прикладной разработчик бизнес-проекта уже в итоге на TypeScript (JavaScript) быстро собирает мобильное приложение как из кубиков, используя готовые компоненты.
Например, в неё входят:
— мобильная библиотека (которая встраивается в мобильные приложения)
— модуль платформу на backend'e
— различные шлюзы (из-за богатой внутренней инфраструктуры)
— инструменты DevOps
— методологии и инструменты тестирования
— средства для сбора мобильной аналитики и логов
и т.д.
Мобильная библиотека — это конструктор приложений в некотором роде, т.к. она основана на принципах разбиения всей функциональности на некоторые блоки — компоненты.
Компоненты бывают визуальными (кнопки, чекбоксы, прогресс-бар, загрузчики, карты и т.д.), из которых выстраивается интерфейс и не визуальными или сервисами (логирование, работа с сетью, удаленное управление и т.д.).
Прикладной разработчик бизнес-проекта уже в итоге на TypeScript (JavaScript) быстро собирает мобильное приложение как из кубиков, используя готовые компоненты.
Тот факт, что в посте нет слов «СберБанк» и «СберТех» — это задумка такая или продолб?
Спасибо за статью, очень интересно! Люблю React Native :)
А вы в каком банке реализуете платформу?
А вы в каком банке реализуете платформу?
Спасибо за статью, уже не первая в которой хвалят React Native.
Недавно читал статью, как разработчики Artsy перешли с Objective-C на Swift, потом на React Native. Подробнее можете прочитать вот здесь. Как понял это не для каждого проекта. Как и всегда есть свои плюсы и минусы. Понравилось, что можно сложные вещи писать на нативном коде Objective-C/Swift и потом интегрировать с React Native. Раньше если у них iOS разработчики были отдельной «эко» системой, то сейчас веб разработчики могут вносить свою помощь.
Недавно читал статью, как разработчики Artsy перешли с Objective-C на Swift, потом на React Native. Подробнее можете прочитать вот здесь. Как понял это не для каждого проекта. Как и всегда есть свои плюсы и минусы. Понравилось, что можно сложные вещи писать на нативном коде Objective-C/Swift и потом интегрировать с React Native. Раньше если у них iOS разработчики были отдельной «эко» системой, то сейчас веб разработчики могут вносить свою помощь.
Спасибо за интересную информацию! Хорошо, что хоть кто-то начал задумываться о том, что react в какой-то момент может захотеться поменять…
Собственно, вопрос у меня как раз на эту тему, точнее даже не вопрос, а просьба показать на примерах, как выглядит весь этот viper-код в совокупности
Интересны следующие нюансы:
- как связываете отображение на react со стейтом в redux, есть ли между ними какая-то прослойка, позволяющая заменить только react или только redux, например?
- как связываете отображение на react и контроллер (ну или ту сущность, которая решает, как менять модель в зависимости от действий пользователя / каких-то внешних действий (тик таймера, например))
Хорошие вопросы. Постараюсь ответить подробно.
Мы делаем наши компоненты stateless на нативном уровне, точнее как мы сами ввели термин valueless.
То есть компонент внутри себя не может изменить значение.
Значения в компонент задаются с уровня JS. А на уровне JS хранятся в redux store.
Давайте на примере компонента TextInput (можете посмотреть видео-материал, там есть этот пример).
На уровне JS TextInput — это React.Component. Когда мы используем его внутри нашего кода мы пишем что-то вида:
Если мы будем вводить текст внутрь нашего компонента — он не будет отображаться, потому что текст не хранится внутри. Чтобы изменения текста отображались внутри TextInput нужно сделать примерно следующее:
Мы возвращаем новое значение введенного текста, сохраняем его в JS и обновляем свойство text у компонента.
Т.е. методология React не нарушается — мы храним значения для наших компонентов не внутри них самих.
Изменения интерфейса также происходят согласно правилам React, например, при изменении state, props или context.
как связываете отображение на react со стейтом в redux, есть ли между ними какая-то прослойка, позволяющая заменить только react или только redux, например?
Мы делаем наши компоненты stateless на нативном уровне, точнее как мы сами ввели термин valueless.
То есть компонент внутри себя не может изменить значение.
Значения в компонент задаются с уровня JS. А на уровне JS хранятся в redux store.
Давайте на примере компонента TextInput (можете посмотреть видео-материал, там есть этот пример).
На уровне JS TextInput — это React.Component. Когда мы используем его внутри нашего кода мы пишем что-то вида:
<TextInput text=''/>
Если мы будем вводить текст внутрь нашего компонента — он не будет отображаться, потому что текст не хранится внутри. Чтобы изменения текста отображались внутри TextInput нужно сделать примерно следующее:
onChange = text => this.setState({text})
...
<TextInput text=this.state.text onChange={this.onChange}/>
Мы возвращаем новое значение введенного текста, сохраняем его в JS и обновляем свойство text у компонента.
Т.е. методология React не нарушается — мы храним значения для наших компонентов не внутри них самих.
как связываете отображение на react и контроллер (ну или ту сущность, которая решает, как менять модель в зависимости от действий пользователя / каких-то внешних действий (тик таймера, например))
Изменения интерфейса также происходят согласно правилам React, например, при изменении state, props или context.
Компонент связывается с redux-стором посредством стандартных биндингов входящих в пакет react-redux, т.е используется Provider и connect.
Компонент — это чистая функция. При изменении стейта React обновляет virtual dom, если параметры компонента(т.е функции) изменились — React Native пробрасывает измененные параметры на нативный уровень(bridge level).
Bridge level конвертирует полученный JSON в нативные типы данных и вызывает соответствующие методы презентера. Презентер смотрит на то, что ему пришло и в каком состоянии он находится. И на основе этого обновляет UIView. UIView состояния не имеет и все свои события пробрасывает в презентер. От презентера опять попадаем в bridge level, React Native пробрасывает события из нативного уровня на уровень JS.
Компонент — это чистая функция. При изменении стейта React обновляет virtual dom, если параметры компонента(т.е функции) изменились — React Native пробрасывает измененные параметры на нативный уровень(bridge level).
Bridge level конвертирует полученный JSON в нативные типы данных и вызывает соответствующие методы презентера. Презентер смотрит на то, что ему пришло и в каком состоянии он находится. И на основе этого обновляет UIView. UIView состояния не имеет и все свои события пробрасывает в презентер. От презентера опять попадаем в bridge level, React Native пробрасывает события из нативного уровня на уровень JS.
Презентер смотрит на то, что ему пришло и в каком состоянии он находится
вот тут хотелось бы поподробней: presenter — это уже какая-то сущность в нативном коде или в js-коде? Получается весь viper-подход содержится только в нативной части и никак не распространяется на разные части js-кода (отображение, хранение данных)?
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
Т.е типичный компонент это:
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 native, то вместе с накопленной частью на redux?
А если планируется отказаться от redux, но оставить react-native — насколько это будет безболезненно?
Можно посмотреть с двух сторон:
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) Со стороны мобильной платформы
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. Но при этом проект продолжит работать в вебе, потеряем только мобильное приложение.
Со стороны проектов отказаться от redux и оставить react-native уже сложнее. Потребуется вносить изменения в js-код. Количество изменений зависит от того, на какой фреймворк/архитектуру мы переходим(mobx/relay/...).
И вот тут не возникало мысли так же применить какой-нибудь из упомянутых подходов, чтобы избежать завязки на конкретную модель хранения / изменения данных? Или это бы наоборот всё усложнило?
Классная статья, спасибо.
Появилось несколько вопросов:
1. Разве за time to market отвечают выбранные технологии (в данном случае React), а не Agile?
2. Как у вас с поиском разработчиков знающих JS и Obj-C?
Появилось несколько вопросов:
1. Разве за time to market отвечают выбранные технологии (в данном случае React), а не Agile?
2. Как у вас с поиском разработчиков знающих JS и Obj-C?
Руслан, привет!
1. Согласен. В первую очередь помогает короткий итерационный цикл итерации, тестирование и выпуска.
А автоматизация всего этого — DevOps.
И в одну из технических задач входит CI/CD модулей платформы и прикладных проектов, использующих их.
2. На разработку внутри платформы мы ищем людей, знающих Оbj-C. JS мы обучаем в процессе.
Я бы даже добавил, что при при написании компонентов куда важнее понимание принципов React и Redux.
1. Согласен. В первую очередь помогает короткий итерационный цикл итерации, тестирование и выпуска.
А автоматизация всего этого — DevOps.
И в одну из технических задач входит CI/CD модулей платформы и прикладных проектов, использующих их.
2. На разработку внутри платформы мы ищем людей, знающих Оbj-C. JS мы обучаем в процессе.
Я бы даже добавил, что при при написании компонентов куда важнее понимание принципов React и Redux.
динамической загрузки JS Bundle в мобильное приложение— это что-то типа CodePush?
Sign up to leave a comment.
Мобильная платформа. Как не бояться ReactNative