Comments 69
Не совсем понятно, мы пишем один код для android и ios, или нужно писать разный код для разных платформ?
Насколько я понимаю, код может быть одинаковым, но в докладе автор говорит о том, что разные платформы имеют свою специфику, и идеологически не правильно делать UX на Android схожим с iOS.
Хорошо бы расширить: один код и для android, ios, и для браузеров.
Они говорят что «write once, run everywhere» не работает, и предлагают «learn once, write everywhere». То есть достаточно понимать идеологию реакта, и можно писать код под разные платформы. Большинство кода скорее всего можно реюзать, но для каждой платформы нужен индивидуальный подход.
А что насчет кастомных контролов (или как это правильно называется в ios)? Судя по презентации, ребята из fb для каждого контрола/компонента пишут свою обертку. Следовательно, пока они не напишут обертку для Х, Х нельзя будет использовать.
Мне тоже интересно, как они планируют создать поддержку кастомных элементов, но к сожалению, об этом пока нет ни слова.
Да, они действительно пишут обертки из React -> Native, но я думаю, что публичный релиз состоится только после того, как они покроют все элементы на обоих платформах.
Да, они действительно пишут обертки из React -> Native, но я думаю, что публичный релиз состоится только после того, как они покроют все элементы на обоих платформах.
React Native это просто XCode-проект с их обёртками. Просто дописываете свою обёртку для своих вьюшек.
UFO just landed and posted this here
Комьюнити быстро подключится :-).
> Соответственно, в момент компиляции приложения, span будет транслирован в Text для iOS и аналогичный компонент на Android (так же для всех поддерживаемых тегов, список которых будет здесь опубликован на момент публичного релиза технологии).
Это не верно. Никакого DOM там не будет. Надо будет использовать компонент <Text />
Это не верно. Никакого DOM там не будет. Надо будет использовать компонент <Text />
Я видел ваш скриншот в презентации, но если обратите внимание на вот этот слайд, то сможете увидеть, что описанный вариант не является единственным. Разумеется, никакого DOM'а там нет, т.к. нет ни браузера, ни его объектной модели. Но это не должно исключать возможности писать на HTML-подобном синтаксисе с последующей трансляцией на нативные компоненты. Как я уже говорил в статье, React Native придерживается идеологии «Learn once, write anywhere», что должно распространяться не только на веб или мобильные приложения отдельно, но и облегчить переход от одного к другому.
Мне катастрофически не нравится, что для ui будут использовать Javascript и css. Это не самые лучшие технологии по многим характеристикам. Использование этих технологий диктуется только лишь тем, что в вебе ничего другого нету. Да здравствует диктатура веба
А что вам нравится больше, чем CSS для этой же задачи?
Дело не в том, что мне нравится что-то больше. Разработчики Android и разработчики iOS как-то жили раньше без CSS, нет? И куча десктопных технологий тоже CSS не используют. Мне не нравится диктатура веба. Вместо того, чтобы перетягивать в веб фишки из мобильной/десктопной разработки; мобильную/десктопную разработку подстраивают под заведомо ограниченные технологии. Это плохо.
Стили написаные на CSS транслируются в нативные атрибуты. Посмотрите презентации, там достаточно интересно все рассказывают.
+ Будет поддержка live-reload, то есть изменения в стилях будет отображаться моментально, не нужно даже заново компилить проект.
+ Будет поддержка live-reload, то есть изменения в стилях будет отображаться моментально, не нужно даже заново компилить проект.
А чем CSS ограничен?
UFO just landed and posted this here
Печалька. Реакт тащит на себя разработчиков, которые могли бы развивать веб-компоненты, npm-пакеты, es6 — в общем, светлое будущее фронтенда. А они, со своей странной технологией и пиаром…
Отнюдь. Реакт развивает и поддерживает es6. Например в 0.13 версии появилась возможность использовать чистые es6-классы. Плюс в коде фреймворка используется большое число es6-фишек. Так что наоборот React старается быть как можно более близким к идиоматическому js. Проблема веб-компонентов прежде всего в том, что у них очень маленькая поддержка в браузерах и они имеют очень ограниченную поддержку в IE-семействе.
Технология замечательная, стоит хотя бы попробовать.
Технология замечательная, стоит хотя бы попробовать.
Простите, но не думаю. Реакт с ES6 это делюзия и насмешки над ES6, после расчленения этого самого ES. Это ни разу ни ES уже, а какая-то фейсбук-бутафория.
Реакт нарушает принципы FIRST (отнюдь не менее чем ангуляр).
Любой фреймворк, выглядящий как
Помимо этого, пройдет мода, ES6 с веб-компонентами станет достаточно хорош и везде (2-3 года), а тысячи никому не нужных реакт-компонентов останутся. Новые разработчики просто не будут хотеть изучать реакт для того, чтобы поддерживать эти старые компоненты (зачем, когда можно все делать нативно?) — так, как сейчас никто не хочет изучать mootools или extjs чтобы поддерживать эти компоненты.
Реакт это очередная конъюнктура, в перспективе создаст море проблем. И чем больше разработчиков будут его использовать — тем больше эти проблемы будут.
Реакт нарушает принципы FIRST (отнюдь не менее чем ангуляр).
Любой фреймворк, выглядящий как
React.createClass, или в общем случае <GodObject>.<doSomething> просто в наглую тянет весь проект на себя. Это приводит к тому, что тысячи пользователей этого модуля вынуждены будут тоже использовать реакт, в то время как могли бы и не.Помимо этого, пройдет мода, ES6 с веб-компонентами станет достаточно хорош и везде (2-3 года), а тысячи никому не нужных реакт-компонентов останутся. Новые разработчики просто не будут хотеть изучать реакт для того, чтобы поддерживать эти старые компоненты (зачем, когда можно все делать нативно?) — так, как сейчас никто не хочет изучать mootools или extjs чтобы поддерживать эти компоненты.
Реакт это очередная конъюнктура, в перспективе создаст море проблем. И чем больше разработчиков будут его использовать — тем больше эти проблемы будут.
Любой фреймворк, выглядящий как 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 нарушает упомянутые вами принципы.
Я понял. С той или иной степенью манипуляций — вы найдете причины использовать реакт, я найду причины использовать чистые инструменты без посредников. Вы найдете недостатки в нативном js, я найду недостатки в реакте. Мы не найдем консенсус, дискуссия бессмысленна.
Однако я не могу не ответить и оставить неравнодушных с неправильным впечатлением.
Именно вашу реакцию я имел в виду под делюзией — последователи начинают проявлять проективную идентификацию, пытаясь оправдать свое решение и увидеть реакт как «союзник» ES6 там, где на самом деле есть лишь пиар технологии.
С целью интереса (с предубеждением я собираю причины не использовать модные фреймворки), распишу, как react не соответствует FIRST.
Вы, к сожалению, несколько неверно интерпретировали весьма полезные принципы в попытке защитить реакт.
Основной посыл Эдди в том, что сложные компоненты/приложения могут быть единственно надежно построены из атомарных, простых, изолированных и хорошо отлаженных модулей, решающих одну задачу и крайне эффективно. Это все приводит к принципам FIRST, из которых следует взаимозаменяемость компонентов. К этому и сам приходишь через несколько лет разработки компонентов.
Всю концепцию FIRST следует рассматривать в контексте потребителя third-party компонентов.
1. Not Focused
Если бы реакт был действительно фокусирован только на эффективном рендеринге (как вы утверждаете), то это был бы шаблонизатор, который можно использовать точечно как зависимость
2. Not Independent
Независимость у компонентов значит, что можно использовать равнозначные компоненты не тревожась, что выкинув что-то одно не сломается другое. К примеру, tooltip не зависит от dropdown, ajax не зависит от dom-traversal. Если выкинуть один — второй будет работать без проблем. В случае с реактом — да, компоненты реакта могут быть организованны независимо друг от друга. Но они все зависят от реакта. Сам по себе реакт и все построенное на нем становится одной жирной зависимостью, которую либо удаляешь полностью со всеми его компонентами, либо не трогаешь, что делает бессмысленным понятие «независимости виджетов реакта». Вы будете использовать реакт с зоопарком виджетов бок о бок с jquery-плагинами/веб-компонентами/простыми компонентами, когда можно было бы этого не делать.
3. Not Reusable
Это значит, что однажды написав компонент (dialog, к примеру), я могу его использовать в каких угодно других проектах. С npm-модулями это работает. С реакт — нет. React is per-project, project-wide. Я не могу заинклудить виджет реакта из соседнего проекта, только скопипастить. В npm/component я всего лишь делаю
4. Not Small
Реакт в базовом минифицированном/зажатом виде — это 36Кб кода + код виджетов. Если учитывать, что размер компонента, такого, как, к примеру, tooltip, составляет всего 7Кб (в среднем — меньше), а средние приложения на чистых компонентах едва достигают 30Кб (что меньше jquery и близко вообще к теоретическому минимуму), то реакт — это большая зависимость, к которой по безалаберности может прибавиться jQuery и бог знает что еще, что в итоге приведет к раздутому JS.
5. Not Testable
То, что вы назвали, не имеет отношения к тестам, это — отладка. Тесты — когда я могу взять компонент, написать для него тест с десятоком манипуляций и описанием нужного поведения и запускать тест каждый раз, когда я изменил код компонента, чтобы быть уверенным, что я ничего не сломал и не потерял старые пофикшенные баги. Все порядочные npm-модули или компоненты это умеют. Для реакта надо мутить что-то свое, так как тестовые фреймворки не понимают по умолчанию ESXML, то бишь JSX. Да и тестовую среду для реакта создавать сложнее, чем для простого модуля.
Помимо всего прочего, реакт недвусмысленно своей концепцией пытается решить то, что решают веб-компоненты (stateless, data-binding), ES6 (templating), только делает он все это весьма специфично. Это конъюнктурная технология, как и coffeescreept, как и jayQuery, и пр. пр., и в скором времени станет достоянием истории.
Однако я не могу не ответить и оставить неравнодушных с неправильным впечатлением.
Именно вашу реакцию я имел в виду под делюзией — последователи начинают проявлять проективную идентификацию, пытаясь оправдать свое решение и увидеть реакт как «союзник» 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, и пр. пр., и в скором времени станет достоянием истории.
Еще кое что.
Вы может и не придадите сейчас значения, но представьте злую иронию, если фейсбук вдруг официально откажется от поддержки реакта? Его ценность резко упадет до странноватого опенсорсного фреймворка, ничем не лучше absurd.js или ractive.js.
В то время как настоящие «боевые» опенсорсные модули будут живы всегда, в той или иной реинкарнации. Не важно, как называется микро-модуль: arr-flatten, array-flatten, amp-array-flatten, _.flatten или это вообще полифил Array.flatten — принципа это не меняет, это — «аксиома».
Вы может и не придадите сейчас значения, но представьте злую иронию, если фейсбук вдруг официально откажется от поддержки реакта? Его ценность резко упадет до странноватого опенсорсного фреймворка, ничем не лучше absurd.js или ractive.js.
В то время как настоящие «боевые» опенсорсные модули будут живы всегда, в той или иной реинкарнации. Не важно, как называется микро-модуль: arr-flatten, array-flatten, amp-array-flatten, _.flatten или это вообще полифил Array.flatten — принципа это не меняет, это — «аксиома».
> веб-компоненты — светлое будущее фронтенда
На самом деле, веб-компоненты — это такая же помойка как Angular, а светлое будущее как раз React.
На самом деле, веб-компоненты — это такая же помойка как Angular, а светлое будущее как раз React.
Примечательно что Facebook сам используется свои поделки, в отличии от всяких гуглов.
Получается что React в этом случае это просто название, без особой смысловой нагрузки или все таки они вкладывают в эту нагрузку «скорость нативности». Пока что выглядит довольно примитивно, но начало положено.
Получается что React в этом случае это просто название, без особой смысловой нагрузки или все таки они вкладывают в эту нагрузку «скорость нативности». Пока что выглядит довольно примитивно, но начало положено.
Ну не особо и использует. Instagram — это достаточно простое приложение c точки зрения фронтенда, и веб-версия — не основное приложение. Angular также используется для youtube на телевизорах, поэтому ваше замечание не совсем справедливо.
Вот когда react будет использоваться на самом FB — вот это будет действительно сильный аргумент.
Вот когда react будет использоваться на самом FB — вот это будет действительно сильный аргумент.
Так его и создавали для использования у себя (это не домашний проект, получивший поддержку компании, как у гугловцев). Пример можно лицезреть на странице создания объявления («Create Ads»).
Facebook это не только timeline: www.youtube.com/watch?v=KYzlpRvWZ6c.
UFO just landed and posted this here
на www.facebook.com и так используется React
если мне не изменяет память, они недавно писали в твиттер, что fb работает не просто на react, а еще и на master-е его.
Гм, да, наврал. Ситуация изменилась, посыпаю голову пеплом — FB работает на react.
Правильно ли я понял, что это суть новый cocos2d/Unity/Corona, только заточенный под приложения, а не под игры, как вышеперечисленные системы?
UFO just landed and posted this here
Что бы понять чем React Native лучше уже существующих Cordova, Titanium и т.д., рекомендую сначала почитать про ReactJS.Так ведь они явно указали чем лучше, нативностью выходного приложения (без всяких WebView и прочих оберток).
Cordova делает гибридное приложение.
cocos2d, Unity и Corona делают нативные приложения.
React Native, как я понял, делает нативное приложение.
Я спрашивал, чем React Native отличается от cocos2d, Unity и Corona. Как я понял, тем в первую очередь, что на нем предполагается делать бизнес-приложения, а не игры.
cocos2d, Unity и Corona делают нативные приложения.
React Native, как я понял, делает нативное приложение.
Я спрашивал, чем React Native отличается от cocos2d, Unity и Corona. Как я понял, тем в первую очередь, что на нем предполагается делать бизнес-приложения, а не игры.
очередной titanium и pixate в одном наборе?
Нативностью выходной апликухи, судя по всему.
нативность — да, но что насчет кастомных контролов? Например, сделать свой контрол и свою анимацию? Я пробовал и титаниум и pixate(точнее freestyle), все они хороши до тех пор, пока нет задачи написать что-то кастомное и когда начинаешь это делать, то встает большой вопрос использования этих решений — проще нативно сразу писать. Какую задачу будет решать reactiveJS native? код для каждой платформы будет свой. Что тогда решается?
Я правильно понимаю, что на поддержку WebGL можно не расчитывать?
Лучшее объяснение зачем всё это нужно: joshaber.github.io/2015/01/30/why-react-native-matters/
По-моему статья вообще ничего не объясняет. Весь её смысл — в первом предложении: «Несколько дней назад Facebook анонсировал React Native — React, который транслируется в композицию нативных элементов мобильных приложений вместо DOM». Дальше про то, что вы можете использовать любой язык, который будет транслироваться в JS (но это не так, если вы хотите использовать JSX) и об общей концепции React. Где там хоть строчка о том, зачем это нужно и почему это лучше PhoneGap, например?
React lets us write our UIs as a pure function of their state.
В статье все описано. Но попробую объяснить еще раз
Как работает phonegap? Если совсем по простому, то он по сути генерит приложение браузер, но который открывает конкретную html страницу. То есть вы по прежнему работаете с html. Минусы этого подхода хорошо описаны в этом самом посте
Если же использовать React Native, то в итоге вы получаете не html страницу, а интерфейс который работает на основе компонентов операционной системы.
Как работает phonegap? Если совсем по простому, то он по сути генерит приложение браузер, но который открывает конкретную html страницу. То есть вы по прежнему работаете с html. Минусы этого подхода хорошо описаны в этом самом посте
В отличие от того же PhoneGap, который при возникновении нативного события блокирует поток и передает управление на JS-код, ожидая его инструкций (собственно, лаги вы можете наблюдать именно из-за этого)
Если же использовать React Native, то в итоге вы получаете не html страницу, а интерфейс который работает на основе компонентов операционной системы.
промахнулся веткой
всю обвязку для доступа к нативным функциям будет писать facebook?
vibro/sound, camera, push/gcm, device и пр. (в phonegap плагинов очень много)
vibro/sound, camera, push/gcm, device и пр. (в phonegap плагинов очень много)
Уже очень многое написано сторонними разработчиками. Можете поискать интересующие Вас модули на react.parts/native
Получается можно иметь общую часть (логику, работу с данными) и разные представления под разные платформы.
Верно?
Sign up to leave a comment.
Анонс React Native