Комментарии 54
Статья супер! Разжевано все до мелочей… Ждем следующий урок! Уже знаю чем я буду заниматься сегодня :)
title: {
fontSize: 20,
color: '#656565'
},

20 это чего? em, rem, px, pt и остальных вариаций размеров в CSS, так-же как и width/height. width: 80 — восемдесят кого? процентов? ну ок, если процентов, от родителя.
Но фонтСайз: 20% получится от чего? какой по дефолту фонт сайз, что за цифры? это 20 сантиметров или 20 километров?

Просто мне не понятно в чем он FZ считает, интуитивно догадываюсь что в пикселях — но хотелось-бы узнать точнее.
этож React Native — ты просто подставляеш цифры а оно само думает как отобразить. т.е. не важно в чем измерять.
ну браузер по дефолту это понимает как пиксели, если в css писать отступ или размеры шрифтов в таком виде, то он поймёт это как px, скорей всего в RN тоже самое

Собранное приложение в итоге из чего состоит? Какие-то эмуляторы js, сервера..?

движок js встраивается определенно — там js не компилится в нативный код.
так что подозреваю что такая же куча говна из рантайма и набора скриптов.

единственное отличие — нативные контролы вместо html.
Единственное отличие «нативного» приложения от react-native'ного это «нативный» код. Кстати не факт что java машина например будет на порядки лучший результат показывать чем v8 портированный на андройд.

С тем же успехом можно node.js назвать «куча говна из рантайма и набора скриптов», но, боюсь вас не поймут.
Понимайте это так что dev server который стоит на вашем компьютере, компилирует бандл при каждом редактировании файлов и отдает эмулятору/телефону. В скомпилированном приложении этот бандл поставляется вместе.
> С тем же успехом можно node.js назвать «куча говна из рантайма и набора скриптов»

а разве это не так?
Для вас кошерны только системы написанные на C, скомпилированные и с максимальной производительностью? наверное по 10 лет на разработку простого проекта тратите.
Все отлично, но вряд ли скорость работы таких приложений будет намного лучше чем, та же реализация phonegap.
На самом деле скорость работы приложений на RN разительно отличается от приложений построенных с помощью phonegap/cordova, приближаясь по быстродействию к нативным. Собственно в этом и заключается прелесть данной технологии — использовать для написания мобильных приложений технологии из веба и на выходе получать качественное приложение. Плюсом также можно отнести обилие технологий, которые можно использовать. Redux, reflux, mobx и т.п. для контроля состояний. Можно использовать другие языки, например TypeScript, ClojureScript, CoffeScript если JS не удовлетворяет потребностям.
В целом мне нравится ReactNative и то как он развивается. Уже и microsoft взялись за его поддержку https://github.com/ReactWindows/react-native-windows.
При чем здесь технологии из веба, js сейчас является одним из наиболее быстро развивающихся языков, и если лет пять назад (насколько я знаю) на нём можно было писать только под браузеры, то сейчас на нём можно писать и бекенд (Node.js), десктоп (nw) и даже игрушки (Unity).
DOM очень медленный. В react-native юзается виртуальный дом который избавлен от практически всего, соответственно многократно быстрее чем обычное html приложение.
поправьте если ошибаюсь, но насколько знаю, тот же facebook, instagram, 2gis и meduza.io в своих мобильных приложениях как раз react используют, жалоб на скорость работы вроде как нет, разве что загружаются чуть дольше обычных
у меня есть опыт разработки на phonegap и react-native и знаете — вы ошибаетесь. Вам нужно обязательно попробовать react-native и вы поймете, что скорость там отличная. Посмотрите в showcase на сайте react-native и попробуйте.

Согласен. По наблюдениям на PhoneGap основные тормоза не от JavaScript, а от медленной отрисовки браузером. В профайлере практически не видно js, одна отрисовка. Тормоза от JavaScript есть только на старте, если js очень много. У нас его уже несколько мегабайт и на Андроид его загрузка занимает несколько секунд.

Спасибо, отличная статья! С нетерпением жду продолжения с описанием процесса для Android-приложения.
Спасибо очень интересная статья, как раз давно уже хотел попробовать React и React Native.
Дефолтное приложение запустилось но когда все удалил из index.ios.js и заменил вашем текстом для HelloWorld,
начал ругаться что «Super expression must either be null or a function, not undefined».
Видать бабел с реактом ругаются на что то… не могу понять…
i.imgur.com/Xa36TNW.png?1

НЛО прилетело и опубликовало эту надпись здесь
WebStorm почти хорошо, но мне не хватает полной поддержки Flow в нём, у React-Native пока сложно с документацией и Flow (работающий хорошо с Atom) очень выручает
Я прочитал статью, прочитал комментарии к оригинальной статье и даже задал свой, но так и не получил ответа на один вопрос. Может, здесь есть знатоки и они ответят мне на него. Вопрос следующий:
Что значит «UI приложения выражается как функция текущего состояния приложения»?

У вас не возникло такого вопроса при переводе?
Любой UI — это функция текущего состояния, разве нет? Вы вводите текст — внешний вид приложения изменяется. Нажимаете кнопку — внешний вид изменяется. Или это что-то из области философии? Если так, то получается какой-то безаппеляционный аргумент против Титаниума.

Любой UI — это функция текущего состояния, разве нет?


С большой натяжкой. В реакте это более строго. Любой реакт компонент содержит два метода: setState и render. Сам компонент и является той функцией состояния.

В других фреймворках возможно двунаправленное движение состояния: компоненты меняют модель. В реакте движение данных из компонента в модель исключено.

Это продвигается как решение проблем сложных приложений, когда сложно понять что и где меняется. Я сейчас делаю проект в такой архитектуре для расширения кругозора. Сейчас вокруг этого подхода очень много эйфории. Правы-ли апологеты подхода покажет время.

Вам не нужно следить за состоянием UI — он всегда рисуется заново на основе текущих данных (не нужно удалять/изменять отработавшие компоненты — просто меняете данные). Из этого вытекает чистота и простота кода.
Плюс, рендер React на самом деле не обновляет UI полностью (хотя с точки зрения разработки это выглядит именно так), а делает атомарные изменения, что положительно влияет на производительность.
Эм, а стили в коде одному мне мешают?
Нельзя ли как-то по-старинке, отделить вид от поведения?
Можно! Лично я предпочитаю делать следующую структуру:

Styles.base.js — в нем объект в котором стили общие для обеих платформ, вида

export default {
    container : {
        flex: 1
    }
};


Styles.ios.js — стили специфичные для iOs:

import BaseStyles from './Styles.base';
import { StyleSheet } from 'react-native';

export default StyleSheet.create([ BaseStyles, {
...
} ]);


Styles.android.js — специфичные для Андроида стили, содержимое аналогично предыдущему

Затем в коде нужного компонента уже делаю что то типа того:

import styles from './Styles'; //При этом подключатся базовые + специфичные только для текущей платформы

....

<View style={styles.container}>
...
</View>


Как-то так. Писал из головы, возможны неточности в деталях.

Можно. Всё можно, это ж JavaScript: ) Можно даже БЕМ-подобную структуру использовать:


app/
  components/
    /some-component/
      some-component.js
      some-component.style.js
      some-component.test.js
Круто, спасибо, как раз хотел в тему вкопаться. Простите, статью пока до конца не прочитал — это надо взять редактор, взять устройство, и тогда уже действовать. Хотелось бы задать вопросы, на которые наверняка можно найти ответы в гугле, но может кто-то может ответить быстро на своём опыте — это всегда дороже
1) Можно ли это в продакшн. Версия реактнейтив ещё не добралась до первой, значит ли это что всё нестабильно, или что много важных фич не хватает?
2) Есть ли у кого опыт кроссплатформенного приложения написаного на React из-под windows? Насколько я понимаю, собирать iOS приложение можно только под макосью, теоретически для этого можно и виртуалкой воспользоваться. Может кто-нибудь уже занимался подобными извращениями?
1. В принципе, можно. Facebook вполне использует, а им виднее готово их поделие или нет. Насчет версии, скорее то что, API еще может меняться (и менялось сильно в 0.18 вроде версии). Каких-то фич и правда не хватает (например, RCTMaps для Android), но это вполне обходимо стороними компонентами. Так что, бояться нечего кроме смены API за которым надо следить. Ну или не обновляться.
var React = require('react-native');


Такое не работает то ли с 0.25 версии, то ли с 0.26. Теперь нужно React импортировать из пакета "react": var React = require('react');. Вот так и работаем, при каждом обновлении react-native приходится что-то переписывать…
Не очень понимаю что имеется в виду под понятием нативные компоненты. В чем разница с Titanium Appcelerator? Допустим мы хотим создать приложение под андроид со списком — js будет транслирован в байт код далвика/art вызывающий внутри активитити условно вида new LinearLayout( ).addView(new ListView())? Тогда сразу возникает миллион вопросов: как нам тут помогает virtual dom и вообще зачем он тут? Зачем нам вообще js движок на девайсе если мы можем транслировать все во время генерации apk?

JavaScript код остается в текстовом виде. JS один из языков, для которых JIT компилятор эффективнее, чем AOT-компиляция. JIT-компилятор видит как исполняется блок кода и может перекомпилировать его "на лету" в случае необходимости. Написать оптимизирующий AOT-компилятор JS крайне затруднительно из-за самого языка программирования.
Virtual DOM нужен для того, чтобы код шарился бежду браузером и нативом. Т.е. у вас остается практически тот же код в браузере и на устройстве.

Насколько я понимаю, вопрос про то, как соотносятся нативное Android/iOS приложение и понятие Shadow DOM (да и вообще, применимо ли к ним DOM)
Несколько разочарую Вас: «On iOS JSC doesn't use JIT due to the absence of writable executable memory in iOS apps.»

пруф: https://facebook.github.io/react-native/docs/javascript-environment.html

Доки по JavaScriptCore говорят об обратном: http://trac.webkit.org/wiki/JavaScriptCore


Предполагаю, что дока по React Native устарела. Действительно, до iOS8 JIT был доступен только для Safari. Однако с релизом iOS 8 компилятором обзавелся и WKWebView: http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/
Предполагаю, что и JavaScriptCore мог им обзовестись.

Кросс-компиляции там нет, выполняется именно javascript, который использует нативные компоненты через предоставляемое ими API.

Virtual DOM позволяет уменьшить количество взаимодействий с API для отрисовки точно так же как и «обычный» React в браузере — дорогостоящее обращение к API идёт только для перерисовки изменённых участков отображения, а не всего шаблона.

Для меня достоинством React Native является так же их «Learn once, write anywhere», Objective-C мне не знаком, а вот React Native не сильно отличается от его браузерного собрата
Вопрос по теме. Делал как здесь описано, но в момент первого подключения fetch возвращает мне TypeError: Network request failed.

Погуглив я нашел вариант, что это из-за localhost но не понятно шде и на что менять.
Что-то мне это напоминает =)

Это вот сейчас всё это медленно, а через 5 лет скорости js на мобилках будут такие быстрые, что на мобилках будут летать самые обычные js-приложения и не нужны все эти замудрости с react-native и прочей чепухой =)

Это как раньше, когда js для браузеров был слабый, использовали тот же Flash для быстрых приложений.
Сейчас флеш умер для программ.

Так что react — это временное решение, которое через 5 лет будет ненужным.
Возможно в будущих версиях мобильных платформ будут зашивать js интерпретатор, как когда то зашивали java. В отличие от Java (хотя я не эксперт в java), в js не будет лишних библиотек. Каждая библиотека будет подгружаться для отдельного приложения или в нём, кешироваться и использоваться. Это позволит снизить скорость загрузки и старта приложений.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 января 2009

Местоположение

Израиль

Численность

1 001–5 000 человек

Дата регистрации

25 марта 2014

Блог на Хабре