Сейчас мобильная платформа для внутреннего использования.
Как только какой-то из модулей выйдет в opensource — мы обязательно об этом расскажем.
Сейчас чудо можно пощупать только работая внутри команды ЕФС :)
У нас есть релизный цикл: определенные правила и даты, когда мы выпускаем версии.
Например, у нас есть 4 больших релиза в год — это квартальные релизы.
У нас есть итерационные релизы, которые происходят по окончанию каждого спринта, т.е. 1 раз в 2 недели.
Также у нас есть релизы с хот-фиксами, которые не привязаны к датам, т.к. происходят при необходимости выпустить патч с исправлением ошибок каких-то версий.
К квартальному релизу у нас есть планирование. В квартале 7 спринтов. В бэклог спринта мы включаем приоритизированные задачи из квартального бэклога. По ходу спринтов смотрим за результативностью, если есть отклонения от запланированного графика — вносим корректировки, переоцениваем задачи. Также есть некоторая выделенная трудомощность на консультирование и исправление ошибок существующих версий.
У нас свой подход к навигации.
Я думаю мы обязательно про него подробно расскажем в одной из следующих статей :)
Пока скажу так, что у нас есть 2 типа навигации:
локальная, основанная на UINavigationController, чтобы сохранять нативный UX
back-end driven, основанная на работе state-машины, именуемой Workflow
При постановке такого вопроса очень важно понимать какой продукт будет разрабатываться и хватает ли библиотеки компонентов, разработанной Facebook (в нашем случае явно не хватает).
Если приложение простое и компонентов от FB хватает — то хороший front-end разработчик, знающий React и Redux напишет приложение достаточно быстро.
Если же нужно вносить модификации и работать с ReactNative на нативном уровне, то по нашему опыту этим должен заниматься уверенный iOS-разработчик, который уже разобрался с жизненным циклом React.
1. Согласен. В первую очередь помогает короткий итерационный цикл итерации, тестирование и выпуска.
А автоматизация всего этого — DevOps.
И в одну из технических задач входит CI/CD модулей платформы и прикладных проектов, использующих их.
2. На разработку внутри платформы мы ищем людей, знающих Оbj-C. JS мы обучаем в процессе.
Я бы даже добавил, что при при написании компонентов куда важнее понимание принципов React и Redux.
как связываете отображение на 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.
Платформа — это многомодульная система.
Например, в неё входят:
— мобильная библиотека (которая встраивается в мобильные приложения)
— модуль платформу на backend'e
— различные шлюзы (из-за богатой внутренней инфраструктуры)
— инструменты DevOps
— методологии и инструменты тестирования
— средства для сбора мобильной аналитики и логов
и т.д.
Мобильная библиотека — это конструктор приложений в некотором роде, т.к. она основана на принципах разбиения всей функциональности на некоторые блоки — компоненты.
Компоненты бывают визуальными (кнопки, чекбоксы, прогресс-бар, загрузчики, карты и т.д.), из которых выстраивается интерфейс и не визуальными или сервисами (логирование, работа с сетью, удаленное управление и т.д.).
Прикладной разработчик бизнес-проекта уже в итоге на TypeScript (JavaScript) быстро собирает мобильное приложение как из кубиков, используя готовые компоненты.
1. Мы не говорим, что нам не подходит ReactNative. Именно он и подходит. Мы говорим, что мы хотим минимизировать риски, которые мы видим в использовании ReactNative.
2. Мы выбрали ReactNative, потому что он является естественным продолжением фреймворка React от того же разработчика. Кроме мобильной платформы есть на текущий момент и web-платформа, написанная на стеке TypeScript, React + Redux. Одной из важной задач мобильной платформы — это унификация API и компонентов с web-платформой, так чтобы можно было создать единую платформу для сборки мобильных и web приложений.
Давайте скажу так: JS-разработчиков в разы больше чем iOS и Android вместе взятых :)
На текущий момент действительно мобильная платформа поддерживает только iOS, но она легко масштабируется к добавлению Android-устройств.
Очень классная платформа, но хочется больше технических подробностей.
Спасибо! Мы только начали цикл статей — в дальнейшем будем раскрывать технические детали каждого конкретного направления / модуля платформы.
Кстати, чем обусловлено то, что вы не приемлете fork-библиотеки?
Мы начали разрабатывать на версии 0.33.0 (iOS), сейчас уже версия 0.41.0
Версии меняются очень быстро — и мы бы не хотели каждый раз вносить изменения в нашу «копию» библиотеки.
Как мы пытались показать в статье — мы стараемся не сильно зависеть от внутренностей ReactNative и используем только минимально необходимую часть для рендеринга компонентов и проброса вызовов из JS в obj-c.
А платформа всем доступна за плату или как там ещё? Или просто внутренней разработкой хвастаетесь?
На текущий момент платформа развивается indoors и используется внутри продуктов банка, но некоторые модули уже скоро попадут в outsource :)
Уверен, что на эту тему будет отдельный анонс и пост.
Хотелось бы подробно, про бекенд, фронтенд и особенно — поддержу приложения.
Мы начинаем цикл статей и будем рассказывать конкретные детали различных аспектов. Спасибо за интерес!
Привет, одна из продукций, которую мы продавали были ягоды, в частности черешня. И были разные мысли как продавать её. У черешни есть косточки, которые нужно куда-то деть. Маркет проходил в крытом помещении — вариант плевать на пол не самый лучший. Класть косточки в то же место, откуда их берёшь — отвратительно. Их нужно куда-то сплевывать, желательно не трогая рукой (про чистые руки отдельная тема — каждому покупателю выдавалась влажная антисептическая салфетка). Плюс нужно понимать, что покупатель гуляет по Маркету, мы стояли у входа и концепция была — «ягоды на ходу». С точки зрения удобства покупателя нужно была занимать ему только одну руку.
Решение оч простое и произвело фурор — 2 стаканчика на степлере, в одном ягоды, в другом косточки
Как только какой-то из модулей выйдет в opensource — мы обязательно об этом расскажем.
Сейчас чудо можно пощупать только работая внутри команды ЕФС :)
У нас есть релизный цикл: определенные правила и даты, когда мы выпускаем версии.
Например, у нас есть 4 больших релиза в год — это квартальные релизы.
У нас есть итерационные релизы, которые происходят по окончанию каждого спринта, т.е. 1 раз в 2 недели.
Также у нас есть релизы с хот-фиксами, которые не привязаны к датам, т.к. происходят при необходимости выпустить патч с исправлением ошибок каких-то версий.
К квартальному релизу у нас есть планирование. В квартале 7 спринтов. В бэклог спринта мы включаем приоритизированные задачи из квартального бэклога. По ходу спринтов смотрим за результативностью, если есть отклонения от запланированного графика — вносим корректировки, переоцениваем задачи. Также есть некоторая выделенная трудомощность на консультирование и исправление ошибок существующих версий.
Я думаю мы обязательно про него подробно расскажем в одной из следующих статей :)
Пока скажу так, что у нас есть 2 типа навигации:
При постановке такого вопроса очень важно понимать какой продукт будет разрабатываться и хватает ли библиотеки компонентов, разработанной Facebook (в нашем случае явно не хватает).
Если приложение простое и компонентов от FB хватает — то хороший front-end разработчик, знающий React и Redux напишет приложение достаточно быстро.
Если же нужно вносить модификации и работать с ReactNative на нативном уровне, то по нашему опыту этим должен заниматься уверенный iOS-разработчик, который уже разобрался с жизненным циклом React.
1. Согласен. В первую очередь помогает короткий итерационный цикл итерации, тестирование и выпуска.
А автоматизация всего этого — DevOps.
И в одну из технических задач входит CI/CD модулей платформы и прикладных проектов, использующих их.
2. На разработку внутри платформы мы ищем людей, знающих Оbj-C. JS мы обучаем в процессе.
Я бы даже добавил, что при при написании компонентов куда важнее понимание принципов React и Redux.
Мы делаем наши компоненты stateless на нативном уровне, точнее как мы сами ввели термин valueless.
То есть компонент внутри себя не может изменить значение.
Значения в компонент задаются с уровня JS. А на уровне JS хранятся в redux store.
Давайте на примере компонента TextInput (можете посмотреть видео-материал, там есть этот пример).
На уровне JS TextInput — это React.Component. Когда мы используем его внутри нашего кода мы пишем что-то вида:
Если мы будем вводить текст внутрь нашего компонента — он не будет отображаться, потому что текст не хранится внутри. Чтобы изменения текста отображались внутри TextInput нужно сделать примерно следующее:
Мы возвращаем новое значение введенного текста, сохраняем его в JS и обновляем свойство text у компонента.
Т.е. методология React не нарушается — мы храним значения для наших компонентов не внутри них самих.
Изменения интерфейса также происходят согласно правилам React, например, при изменении state, props или context.
Например, в неё входят:
— мобильная библиотека (которая встраивается в мобильные приложения)
— модуль платформу на backend'e
— различные шлюзы (из-за богатой внутренней инфраструктуры)
— инструменты DevOps
— методологии и инструменты тестирования
— средства для сбора мобильной аналитики и логов
и т.д.
Мобильная библиотека — это конструктор приложений в некотором роде, т.к. она основана на принципах разбиения всей функциональности на некоторые блоки — компоненты.
Компоненты бывают визуальными (кнопки, чекбоксы, прогресс-бар, загрузчики, карты и т.д.), из которых выстраивается интерфейс и не визуальными или сервисами (логирование, работа с сетью, удаленное управление и т.д.).
Прикладной разработчик бизнес-проекта уже в итоге на TypeScript (JavaScript) быстро собирает мобильное приложение как из кубиков, используя готовые компоненты.
2. Мы выбрали ReactNative, потому что он является естественным продолжением фреймворка React от того же разработчика. Кроме мобильной платформы есть на текущий момент и web-платформа, написанная на стеке TypeScript, React + Redux. Одной из важной задач мобильной платформы — это унификация API и компонентов с web-платформой, так чтобы можно было создать единую платформу для сборки мобильных и web приложений.
На текущий момент действительно мобильная платформа поддерживает только iOS, но она легко масштабируется к добавлению Android-устройств.
Спасибо! Мы только начали цикл статей — в дальнейшем будем раскрывать технические детали каждого конкретного направления / модуля платформы.
Мы начали разрабатывать на версии 0.33.0 (iOS), сейчас уже версия 0.41.0
Версии меняются очень быстро — и мы бы не хотели каждый раз вносить изменения в нашу «копию» библиотеки.
Как мы пытались показать в статье — мы стараемся не сильно зависеть от внутренностей ReactNative и используем только минимально необходимую часть для рендеринга компонентов и проброса вызовов из JS в obj-c.
На текущий момент платформа развивается indoors и используется внутри продуктов банка, но некоторые модули уже скоро попадут в outsource :)
Уверен, что на эту тему будет отдельный анонс и пост.
Мы начинаем цикл статей и будем рассказывать конкретные детали различных аспектов. Спасибо за интерес!
Начало было захватывающее и не поверхностное, а вот концовки нет. Была хорошая завязка, сюжет, но нет конца…
Решение оч простое и произвело фурор — 2 стаканчика на степлере, в одном ягоды, в другом косточки