Анонс React Native



    Не так давно в Калифронии прошла конференция по React.js (доклады с этой конференции уже размещены на канале facebook разработчиков в youtube). Доклады, как не сложно догадаться, были о различных возможностях React.js и применении их в реальной жизни, но два доклада презентовали исключительно новую технологию, бета-версия которой в данный момент доступна только для разработчиков, посетивших мероприятие. Если вы уже посмотрели доклады, то понимаете, что речь идет о React Native. В данной статье я хочу сделать краткий обзор того, что нас ждёт в будущем с этой технологией и как изменится наше представление о создании мобильных приложений с использованием JavaScript.

    Что такое React Native?


    Итак, давайте разберемся что такое React Native и для каких целей инженеры facebook изобрели эту технологию. Но перед этим, я хочу вас спросить, что вы думаете насчёт Apache Cordova? Медленно? Плавный UI — миф? Лучше использовать WebView с обвязкой на JS? Да-да, так оно и было до анонса React Native. Представьте себе, что в течении пары ближайших месяцев произойдет релиз гибридной системы от facebook на основе React.js и взаимодействия с родными элементами iOS / Android систем (т.е. не создавать WebView, как это делает PhoneGap, но использовать встроенные компоненты, которые предоставляют вышеуказанные платформы). Такой подход позволит разработчикам, уже знакомым с React.js, в схожей манере разрабатывать нативные приложения. React Native не использует ни браузер, ни WebView — только JavaScript API поверх нативных компонентов. Позвольте пояснить как это работает: вы пишете JavaScript код (имхо, скорее всего это будет JSX код), и он работает с нативными компонентами операционной системы, под которую вы разрабатываете, тем самым перенося достоинства и удобства использования React.js из браузера в мобильные приложения. В отличие от того же PhoneGap, который при возникновении нативного события блокирует поток и передает управление на JS-код, ожидая его инструкций (собственно, лаги вы можете наблюдать именно из-за этого), React Native выполняет JS в отдельном фоновом потоке, взаимодействуя с главным потоком асинхронно, т.е. в потоке JS собирается ряд команд к главному потоку и в определенный момент времени, отправляется сгруппированный запрос (batch-запрос), тем самым никак не блокируя главный поток выполнения программы (как это работает в жизни можно посмотреть тут или скачать приложение facebook groups, которое скоро появится в AppStore).

    Как насчёт стилей?


    Тут надо сразу сказать, что facebook не остановился на использовании HTML-like синтаксиса в JS(X) файлах, и следующим решением было использовать CSS-объектную нотацию (сродни той, что можно использовать в браузерах) в рамках мобильных приложений. Это дает ряд неоспоримых преимуществ, например вы можете вычислять количественные свойства элементов (таких как цвет, толщина, размер и т.п.) прямо на лету в ходе выполнения программы и инкапсулировать стили на уровне с вашими компонентами. Выглядит это так:

    var styles = {
      textStyle: {
        color: 'yellow',
        fontSize: 14
      }
    };
    
    React.render(<Text style={styles.textStyle}>Test</Text>, document.body);
    


    Как вы могли заметить, вместо привычного используется <Text/>. Это обусловлено именами компонентов на iOS и Android платформах. Финальная реализация портирования JSX на мобильные платформы пока что остается загадкой (но насколько понятно из презентаций, для каждой платформы будет свой специфический набор тегов для JSX).

    В завершении обзора хочу сказать, что идеей React Native не является поддержка идеологии "Write once, run anywhere" (Однажды написав код, вы можете использовать его на всех платформах), но "Learn once, write anywhere" (Научившись однажды, вы можете писать для любой платформы).

    В статье использовались материалы и информация из видео:
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 68
    • 0
      Не совсем понятно, мы пишем один код для android и ios, или нужно писать разный код для разных платформ?
      • +2
        Насколько я понимаю, код может быть одинаковым, но в докладе автор говорит о том, что разные платформы имеют свою специфику, и идеологически не правильно делать UX на Android схожим с iOS.
        • 0
          Хорошо бы расширить: один код и для android, ios, и для браузеров.
          • +10
            Они говорят что «write once, run everywhere» не работает, и предлагают «learn once, write everywhere». То есть достаточно понимать идеологию реакта, и можно писать код под разные платформы. Большинство кода скорее всего можно реюзать, но для каждой платформы нужен индивидуальный подход.
          • +1
            А что насчет кастомных контролов (или как это правильно называется в ios)? Судя по презентации, ребята из fb для каждого контрола/компонента пишут свою обертку. Следовательно, пока они не напишут обертку для Х, Х нельзя будет использовать.
            • 0
              Мне тоже интересно, как они планируют создать поддержку кастомных элементов, но к сожалению, об этом пока нет ни слова.
              Да, они действительно пишут обертки из React -> Native, но я думаю, что публичный релиз состоится только после того, как они покроют все элементы на обоих платформах.
              • +2
                React Native это просто XCode-проект с их обёртками. Просто дописываете свою обёртку для своих вьюшек.
                • 0
                  Мы пытаемся упростить процесс написания «оберток» насколько это возможно. Библиотека будет позволять разработчикам подключать свои модули, т.е. не обязательно будет ждать пока нужный вам компонент появится в React Native.
                  • 0
                    Комьюнити быстро подключится :-).
                  • –15
                    reactos Jeditobe в суд на Facebook подавать будете?
                    • +2
                      > Соответственно, в момент компиляции приложения, span будет транслирован в Text для iOS и аналогичный компонент на Android (так же для всех поддерживаемых тегов, список которых будет здесь опубликован на момент публичного релиза технологии).

                      Это не верно. Никакого DOM там не будет. Надо будет использовать компонент <Text />
                      • 0
                        Я видел ваш скриншот в презентации, но если обратите внимание на вот этот слайд, то сможете увидеть, что описанный вариант не является единственным. Разумеется, никакого DOM'а там нет, т.к. нет ни браузера, ни его объектной модели. Но это не должно исключать возможности писать на HTML-подобном синтаксисе с последующей трансляцией на нативные компоненты. Как я уже говорил в статье, React Native придерживается идеологии «Learn once, write anywhere», что должно распространяться не только на веб или мобильные приложения отдельно, но и облегчить переход от одного к другому.
                        • +1
                          Вы послушайте, что он говорит в это время: «Мы имеем набор примитивов в вебе, например div, span, img, но на нативных платформах мы имеем другой набор примитивов.

                          Этот слайд ничего не говорит об автоматическом конвертировании. Он говорит, что они будут другие.
                          • 0
                            Ох, да, вы правы, сейчас исправлю!
                      • –9
                        Мне катастрофически не нравится, что для ui будут использовать Javascript и css. Это не самые лучшие технологии по многим характеристикам. Использование этих технологий диктуется только лишь тем, что в вебе ничего другого нету. Да здравствует диктатура веба
                        • +9
                          А что вам нравится больше, чем CSS для этой же задачи?
                          • –1
                            Дело не в том, что мне нравится что-то больше. Разработчики Android и разработчики iOS как-то жили раньше без CSS, нет? И куча десктопных технологий тоже CSS не используют. Мне не нравится диктатура веба. Вместо того, чтобы перетягивать в веб фишки из мобильной/десктопной разработки; мобильную/десктопную разработку подстраивают под заведомо ограниченные технологии. Это плохо.
                            • +4
                              Стили написаные на CSS транслируются в нативные атрибуты. Посмотрите презентации, там достаточно интересно все рассказывают.

                              + Будет поддержка live-reload, то есть изменения в стилях будет отображаться моментально, не нужно даже заново компилить проект.
                              • –9
                                Ну так и JS в любом случае транслируется в машинный код. Однако от этого он не перестаёт быть убогим (не в обиду js-разработчикам).
                                • +4
                                  Можно будет писать на других языках, которые транслируются в JavaScript (Typescript, ClojureScript, Scala-JS, etc.) Код, который вы видели в презентации использует фичи ECMAScript 6 и JSX. JavaScriptCore (JS рантайм в iOS) не понимает этого синтаксиса, поэтому в состав React Native уже входит упаковщик, который умеет на лету транслировать код в ECMAScript 5.
                              • +1
                                А чем CSS ограничен?
                                • +4
                                  Возможно вы не знакомы с Flexbox? Я разрабатывал UI приложений для iOS (interface builder, код и auto layout), Android (XML android:layout) и web (CSS). Я считаю подмножество CSS, которое используется в React Native (Flexbox), самым удобным и простым в изучении инструментом.

                                  Обратите внимание, поддерживается только подмножество CSS без таблиц, хитрых `float` и `z-index`.

                                  Расскажите, пожалуйста, чем CSS ограничен и какие фишки из мобильной/десктопной разработки вы имеете ввиду.
                            • –3
                              Печалька. Реакт тащит на себя разработчиков, которые могли бы развивать веб-компоненты, npm-пакеты, es6 — в общем, светлое будущее фронтенда. А они, со своей странной технологией и пиаром…
                              • 0
                                Отнюдь. Реакт развивает и поддерживает es6. Например в 0.13 версии появилась возможность использовать чистые es6-классы. Плюс в коде фреймворка используется большое число es6-фишек. Так что наоборот React старается быть как можно более близким к идиоматическому js. Проблема веб-компонентов прежде всего в том, что у них очень маленькая поддержка в браузерах и они имеют очень ограниченную поддержку в IE-семействе.

                                Технология замечательная, стоит хотя бы попробовать.
                                • –2
                                  Простите, но не думаю. Реакт с ES6 это делюзия и насмешки над ES6, после расчленения этого самого ES. Это ни разу ни ES уже, а какая-то фейсбук-бутафория.

                                  Реакт нарушает принципы FIRST (отнюдь не менее чем ангуляр).
                                  Любой фреймворк, выглядящий как React.createClass, или в общем случае <GodObject>.<doSomething> просто в наглую тянет весь проект на себя. Это приводит к тому, что тысячи пользователей этого модуля вынуждены будут тоже использовать реакт, в то время как могли бы и не.
                                  Помимо этого, пройдет мода, ES6 с веб-компонентами станет достаточно хорош и везде (2-3 года), а тысячи никому не нужных реакт-компонентов останутся. Новые разработчики просто не будут хотеть изучать реакт для того, чтобы поддерживать эти старые компоненты (зачем, когда можно все делать нативно?) — так, как сейчас никто не хочет изучать mootools или extjs чтобы поддерживать эти компоненты.

                                  Реакт это очередная конъюнктура, в перспективе создаст море проблем. И чем больше разработчиков будут его использовать — тем больше эти проблемы будут.
                                  • +8
                                    Любой фреймворк, выглядящий как React.createClass просто в наглую тянет весь проект на себя.


                                    Это было справедливо до 13 версии. Теперь создание компонента выглядит так:
                                    export class Counter extends React.Component {
                                      constructor(props) {
                                        super(props);
                                        this.state = {count: props.initialCount};
                                      }
                                      tick() {
                                        this.setState({count: this.state.count + 1});
                                      }
                                      render() {
                                        return (
                                          <div onClick={this.tick.bind(this)}>
                                            Clicks: {this.state.count}
                                          </div>
                                        );
                                      }
                                    }
                                    


                                    Теперь по поводу нарушений принципов FIRST:
                                    Keep it (F)ocused
                                    Основной фокус реакта — сделать повторный рендеринг виджета как можно более простым. Именно поэтому внутри самой сути заложено разделение на маленькие компоненты, которые выполняют возложенную на них функцию.

                                    Keep it (I)ndependent
                                    Виджеты независимы друг от друга, это достигается за счет введения понятия props и one-way binding. Т.е. каждый виджет это почти «чистая функция», который на вход принимает набор аргументов и на его основе рендерит верстку. Мы можем взять виджет, перенести его в другое место страницы и подать ему те же самые свойства, при этом результат рендеринга не изменится, т.к. не зависит от окружающих компонентов.

                                    Keep it ®eusable
                                    В идеале компоненты должны быть stateless, т.е. они не содержат внутреннего состояния и рендерятся каждый раз одинаково, когда им на вход подают одинаковые входные аргументы. см. пример выше.

                                    Keep it (S)mall
                                    Виджеты для Реакта как правило очень маленькие, каждый файл с ними редко превышает размер 100 строк, если все же превышает, то это звоночек, чтобы задуматься о разнесении виджета на несколько или вынесение утильного кода в хелперы.

                                    Keep it (T)estable
                                    Протестировать виджет, который является stateless очень просто, т.к. подаешь ему одни и те же свойства и смотришь совпадает ли верстка, поэтому очень легко тестировать как приложение в целом, так и каждый виджет в отдельности.

                                    Честно говоря, так и не нашел в каком месте React нарушает упомянутые вами принципы.
                                    • –2
                                      Я понял. С той или иной степенью манипуляций — вы найдете причины использовать реакт, я найду причины использовать чистые инструменты без посредников. Вы найдете недостатки в нативном js, я найду недостатки в реакте. Мы не найдем консенсус, дискуссия бессмысленна.

                                      Однако я не могу не ответить и оставить неравнодушных с неправильным впечатлением.

                                      Именно вашу реакцию я имел в виду под делюзией — последователи начинают проявлять проективную идентификацию, пытаясь оправдать свое решение и увидеть реакт как «союзник» ES6 там, где на самом деле есть лишь пиар технологии.

                                      С целью интереса (с предубеждением я собираю причины не использовать модные фреймворки), распишу, как react не соответствует FIRST.

                                      Вы, к сожалению, несколько неверно интерпретировали весьма полезные принципы в попытке защитить реакт.
                                      Основной посыл Эдди в том, что сложные компоненты/приложения могут быть единственно надежно построены из атомарных, простых, изолированных и хорошо отлаженных модулей, решающих одну задачу и крайне эффективно. Это все приводит к принципам FIRST, из которых следует взаимозаменяемость компонентов. К этому и сам приходишь через несколько лет разработки компонентов.
                                      Всю концепцию FIRST следует рассматривать в контексте потребителя third-party компонентов.

                                      1. Not Focused
                                      Если бы реакт был действительно фокусирован только на эффективном рендеринге (как вы утверждаете), то это был бы шаблонизатор, который можно использовать точечно как зависимость import render from 'React' (как это делает любой порядочный шаблонизатор), и который можно легко заменить. В данном случае реакт — это цементированный фундамент для построения компонентов только на нем. Почему он не focused? Потому что не разделяет ответственность (SoC), решает целый список задач: создание классов (до ES6 ненативно), шаблонизация, менеджинг состояний, диспетчер событий и пр. аддоны. Focused бы значило, что под каждую задачу есть свой инструмент, а такие инструменты есть.

                                      2. Not Independent
                                      Независимость у компонентов значит, что можно использовать равнозначные компоненты не тревожась, что выкинув что-то одно не сломается другое. К примеру, tooltip не зависит от dropdown, ajax не зависит от dom-traversal. Если выкинуть один — второй будет работать без проблем. В случае с реактом — да, компоненты реакта могут быть организованны независимо друг от друга. Но они все зависят от реакта. Сам по себе реакт и все построенное на нем становится одной жирной зависимостью, которую либо удаляешь полностью со всеми его компонентами, либо не трогаешь, что делает бессмысленным понятие «независимости виджетов реакта». Вы будете использовать реакт с зоопарком виджетов бок о бок с jquery-плагинами/веб-компонентами/простыми компонентами, когда можно было бы этого не делать.

                                      3. Not Reusable
                                      Это значит, что однажды написав компонент (dialog, к примеру), я могу его использовать в каких угодно других проектах. С npm-модулями это работает. С реакт — нет. React is per-project, project-wide. Я не могу заинклудить виджет реакта из соседнего проекта, только скопипастить. В npm/component я всего лишь делаю
                                      npm install component-dialog
                                      . И всё.

                                      4. Not Small
                                      Реакт в базовом минифицированном/зажатом виде — это 36Кб кода + код виджетов. Если учитывать, что размер компонента, такого, как, к примеру, tooltip, составляет всего 7Кб (в среднем — меньше), а средние приложения на чистых компонентах едва достигают 30Кб (что меньше jquery и близко вообще к теоретическому минимуму), то реакт — это большая зависимость, к которой по безалаберности может прибавиться jQuery и бог знает что еще, что в итоге приведет к раздутому JS.

                                      5. Not Testable
                                      То, что вы назвали, не имеет отношения к тестам, это — отладка. Тесты — когда я могу взять компонент, написать для него тест с десятоком манипуляций и описанием нужного поведения и запускать тест каждый раз, когда я изменил код компонента, чтобы быть уверенным, что я ничего не сломал и не потерял старые пофикшенные баги. Все порядочные npm-модули или компоненты это умеют. Для реакта надо мутить что-то свое, так как тестовые фреймворки не понимают по умолчанию ESXML, то бишь JSX. Да и тестовую среду для реакта создавать сложнее, чем для простого модуля.

                                      Помимо всего прочего, реакт недвусмысленно своей концепцией пытается решить то, что решают веб-компоненты (stateless, data-binding), ES6 (templating), только делает он все это весьма специфично. Это конъюнктурная технология, как и coffeescreept, как и jayQuery, и пр. пр., и в скором времени станет достоянием истории.
                                      • –1
                                        Еще кое что.
                                        Вы может и не придадите сейчас значения, но представьте злую иронию, если фейсбук вдруг официально откажется от поддержки реакта? Его ценность резко упадет до странноватого опенсорсного фреймворка, ничем не лучше absurd.js или ractive.js.
                                        В то время как настоящие «боевые» опенсорсные модули будут живы всегда, в той или иной реинкарнации. Не важно, как называется микро-модуль: arr-flatten, array-flatten, amp-array-flatten, _.flatten или это вообще полифил Array.flatten — принципа это не меняет, это — «аксиома».
                                  • +6
                                    > веб-компоненты — светлое будущее фронтенда

                                    На самом деле, веб-компоненты — это такая же помойка как Angular, а светлое будущее как раз React.
                                    • 0
                                      Классно обменялись аргументами :)
                                  • 0
                                    Примечательно что Facebook сам используется свои поделки, в отличии от всяких гуглов.

                                    Получается что React в этом случае это просто название, без особой смысловой нагрузки или все таки они вкладывают в эту нагрузку «скорость нативности». Пока что выглядит довольно примитивно, но начало положено.
                                    • 0
                                      Ну не особо и использует. Instagram — это достаточно простое приложение c точки зрения фронтенда, и веб-версия — не основное приложение. Angular также используется для youtube на телевизорах, поэтому ваше замечание не совсем справедливо.
                                      Вот когда react будет использоваться на самом FB — вот это будет действительно сильный аргумент.
                                      • 0
                                        Так его и создавали для использования у себя (это не домашний проект, получивший поддержку компании, как у гугловцев). Пример можно лицезреть на странице создания объявления («Create Ads»).
                                        • 0
                                          То, как зародился проект — не особо важно. Gmail вроде как тоже проект, выродившийся из 20% свободного времени, ровно как и Rust, на пример.
                                        • 0
                                          Facebook это не только timeline: www.youtube.com/watch?v=KYzlpRvWZ6c.
                                          • +1
                                            Вы не правы, использует. Поиск по коду фронтенда выдает больше 10000 компонент. Огромная часть используется в интерфейсе Ads Manager, комментариях, редакторе профиля, интерфейсе выбора стикеров, и т.д., включая бесчисленное количество внутренних систем.

                                            На React полностью написан t.facebook.com/ — новая web-версия Facebook для планшетов.
                                            • +1
                                              на www.facebook.com и так используется React
                                              • +1
                                                если мне не изменяет память, они недавно писали в твиттер, что fb работает не просто на react, а еще и на master-е его.
                                                • 0
                                                  Гм, да, наврал. Ситуация изменилась, посыпаю голову пеплом — FB работает на react.
                                              • –1
                                                Правильно ли я понял, что это суть новый cocos2d/Unity/Corona, только заточенный под приложения, а не под игры, как вышеперечисленные системы?
                                                • +1
                                                  Простите, не понял вопрос. У них совершенно разные цели, кроме кроссплатформенности. React Native —  это порт ReactJS на мобильные платформы, который вместо DOM использует компоненты системы для отображения UI. Основная фишка — возможность описывать UI как «чистую» функцию (pure function) от данных и состояния. Это позволяет переложить ответственность за обновление интерфейса на библиотеку. Что бы понять чем React Native лучше уже существующих Cordova, Titanium и т.д., рекомендую сначала почитать про ReactJS.

                                                  • +1
                                                    Что бы понять чем React Native лучше уже существующих Cordova, Titanium и т.д., рекомендую сначала почитать про ReactJS.
                                                    Так ведь они явно указали чем лучше, нативностью выходного приложения (без всяких WebView и прочих оберток).
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                      • +2
                                                        Если так, то не вижу смысла в реактовых велосипедах.
                                                        • +1
                                                          А смысл вот в чем.

                                                          Что у них общего:

                                                          — предоставляют возможность использовать API платформы с JavaScript.
                                                          — UI состоит из нативных компонент

                                                          В чем разница

                                                          — Titanium предоставляет императивный API: создай окно, создай кнопку и т.д. Когда в приложении что-то меняется, разработчику надо это делать все руками — менять содержимое элементов UI (пример). У React другая модель — программист описывает то, как выглядят его компоненты в зависимости от состояния приложения, а React сам обновляет UI когда меняется состояние (пример, см. A Stateful Component). Модель React намного удобней как в начале разработки, так и когда приложение становится очень большим.
                                                          • –1
                                                            react native = titanium + 2 way data binding (mvp)?
                                                            • +1
                                                              если что, у реакта нет 2-way binding по умолчанию. это чисто view.
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                    • 0
                                                      Cordova делает гибридное приложение.
                                                      cocos2d, Unity и Corona делают нативные приложения.
                                                      React Native, как я понял, делает нативное приложение.
                                                      Я спрашивал, чем React Native отличается от cocos2d, Unity и Corona. Как я понял, тем в первую очередь, что на нем предполагается делать бизнес-приложения, а не игры.
                                                      • 0
                                                        В контексте предназначения — да, на React Native удобно писать приложения, не игры.
                                                  • 0
                                                    очередной titanium и pixate в одном наборе?
                                                    • 0
                                                      Нативностью выходной апликухи, судя по всему.
                                                      • +1
                                                        нативность — да, но что насчет кастомных контролов? Например, сделать свой контрол и свою анимацию? Я пробовал и титаниум и pixate(точнее freestyle), все они хороши до тех пор, пока нет задачи написать что-то кастомное и когда начинаешь это делать, то встает большой вопрос использования этих решений — проще нативно сразу писать. Какую задачу будет решать reactiveJS native? код для каждой платформы будет свой. Что тогда решается?

                                                        • +2
                                                          Я тоже придерживаюсь мнения что если использовать всякие абстракции от родных sdk, то только для простых приложений. А по поводу этого react native у меня впечатление что им там работы не хватает вот и страдают фигней всякой.
                                                          • 0
                                                            Если они могут «страдая фигнёй» сделать огромный шаг в улучшении средств мобильной разработки – это круто.
                                                    • 0
                                                      Я правильно понимаю, что на поддержку WebGL можно не расчитывать?
                                                      • 0
                                                        Далеко не факт. На сколько я понимаю — webgl является биндингом к opengl, а значит в react native нужно просто портировать canvas. Единственное — думаю это не самая приоритетная фича.
                                                      • 0
                                                        Лучшее объяснение зачем всё это нужно: joshaber.github.io/2015/01/30/why-react-native-matters/
                                                        • 0
                                                          По-моему статья вообще ничего не объясняет. Весь её смысл — в первом предложении: «Несколько дней назад Facebook анонсировал React Native — React, который транслируется в композицию нативных элементов мобильных приложений вместо DOM». Дальше про то, что вы можете использовать любой язык, который будет транслироваться в JS (но это не так, если вы хотите использовать JSX) и об общей концепции React. Где там хоть строчка о том, зачем это нужно и почему это лучше PhoneGap, например?
                                                          • 0
                                                            React lets us write our UIs as a pure function of their state.
                                                            • 0
                                                              Это о React, но не о React Native (разумеется, что для него это тоже справедливо, но это не ключевая особенность Native'a)
                                                            • 0
                                                              В статье все описано. Но попробую объяснить еще раз

                                                              Как работает phonegap? Если совсем по простому, то он по сути генерит приложение браузер, но который открывает конкретную html страницу. То есть вы по прежнему работаете с html. Минусы этого подхода хорошо описаны в этом самом посте
                                                              В отличие от того же PhoneGap, который при возникновении нативного события блокирует поток и передает управление на JS-код, ожидая его инструкций (собственно, лаги вы можете наблюдать именно из-за этого)


                                                              Если же использовать React Native, то в итоге вы получаете не html страницу, а интерфейс который работает на основе компонентов операционной системы.
                                                          • 0
                                                            промахнулся веткой
                                                            • 0
                                                              всю обвязку для доступа к нативным функциям будет писать facebook?
                                                              vibro/sound, camera, push/gcm, device и пр. (в phonegap плагинов очень много)
                                                              • 0
                                                                Уже очень многое написано сторонними разработчиками. Можете поискать интересующие Вас модули на react.parts/native
                                                                • 0

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


                                                                  Верно?

                                                                  • 0
                                                                    Да, если не требуется какой-то кастомной логики под отдельно взятую платформу.

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.