React Native. Пишемо нативні додатки для iOS і Android

1. Що таке React Native
2. Стилі React Native
3. Два способи розділяти платформозавісімую логіку
4. Переваги React Native

Чому нам так подобаються нативні додатки? Чому, якщо нам потрібно замовити таксі, ми не заходимо на gett.com або uber.com через браузер, а замовляємо таксі через додаток? Замовляти таксі через додаток набагато зручніше. У Gett і Uber просто-напросто немає веб-додатків: люди вже настільки звикли користуватися нативними, що в наш час без них бути конкурентоспроможним дуже складно.

Звичайно, є цілком певні причини популярності нативних додатків:

• Швидкість і чуйність. Нативні додатки, як правило, низькорівневими оптимізовані під платформу, на якій запускаються.
• Підтримка складних жестів і нетривіальною анімації.
• Однаковий UI. Інтерфейс різних додатків в межах однієї ОС побудований приблизно однаково: звичайно, компоненти варіюються від програми до програми, але принцип дії приблизно однаковий. Т. е., Якщо ви розберетеся в інтерфейсі однієї програми, вам буде простіше розібратися і в інтерфейсі інших додатків на тій же ОС.

Незважаючи на популярність нативних додатків, створювати їх досить важко з таких причин:

• Різний набір технологій: наприклад, якщо вам потрібно зробити один додаток для Android і iOS, вам доводиться наймати і Android-розробників, і iOS-розробників - і це, звичайно ж, дорожче.
• Т. к. Технології різні, немає повторного використання коду. Наприклад, якщо потрібно посилати REST API-запит на хмарний сервер, доводиться писати шар служб і для Android, і для iOS. Потім нам доводиться два рази писати один і той же UI, два рази писати якусь одну функцію і т. Д.
• Доводиться робити нову збірку на кожну зміну, що займає досить багато часу і уповільнює швидкість ітерацій.

Застосування веб-програмування вирішує всі ці проблеми:

• Набір технологій один: нам досить знати HTML, JS і CSS.
• Багато повторно використовуваного коду: можна знайти величезну кількість JS-бібліотек.
• Легко вносити зміни - досить оновити сторінку, щоб їх побачити.

З цих причин веб-підхід спробували застосувати на мобільних додатках -для цього є такі інструменти, як PhoneGap, Appcelerator Titanium, Ionic і т. Д. Вони беруть WebView і представляють його у вигляді нативного додатки, але насправді це - всього лише HTML , JS і CSS.

В принципі, такий підхід працює, але, як би ви не старалися, все одно не вийде зробити все так красиво, як у справжньому нативном додатку (наприклад, дуже складно буде зробити анімовані краю, до яких ми звикли в iOS).

Що таке React Native

Раніше дуже багато компаній робили ставку на застосування HTML5 в додатках, - наприклад, Facebook, поки в 2012 р Цукерберг не оголосив, що вони відмовляються від такого підходу. А в 2015 р Facebook випускає свій перший додаток на React Native - Ads Manager, додаток для управління рекламою.

До появи React Native нам доводилося вирішувати, ніж нам потрібно пожертвувати, - зручністю користувача або зручністю розробника. Іншими словами, що вибрати, - дешевшу і просту розробку на шкоду досвіду користувача, або приголомшливий досвід користувача, але складну і дорогу розробку? Facebook вирішив, що і те, і інше важливо, і створив React Native.

Що таке React Native? Це JS-фреймворк, заснований на JS і React - JS-бібліотеці для створення UI (View-рівня).

Концепція React Native дуже проста. Я її проілюструю на наступному прикладі: припустимо, у мене є дуже просте додаток, що складається з кнопки "add + 1" і елемента "count", значення якого збільшується на 1 при натисканні кнопки:

Як воно написано? За допомогою функції UI = f (count) React Native - це, мабуть, квінтесенція компонентного підходу. Будь-атомарний елемент - це компонент. А компонент - по суті, функція, яка на вхід приймає набір параметрів, а на виході при даному наборі вхідних параметрів завжди дає однаковий вихід. Тобто виконання функції не залежить від оточення - функція ізольована.

У нашого застосування наступний код:

UI = f (count) = div (span ( 'Count' + count), button ( 'Add + 1'))

Це поки ще не React, а чисто умоглядна модель. Ходімо далі - розширимо код до наступного рівня, ближче до JS (але ще не до React):

render () {return (div (span ( 'Count:' + b (this.state.count)), button ( 'Add +1')))}

Тут у нас є функція "render", у якій є стан (це "count").

А тепер розглянемо код в React. У порівнянні з попередньою моделлю, тут є деякі поліпшення синтаксису:

render () {return (<div> <span> Count: <b> {this.state.count} </ b> </ span> <button> Add +1 </ button> </ div>)}

Тут всередині "return" ви бачите JSX - код, який виконаний в стилі HTML5 і тому всім інтуїтивно зрозумілий. А в процесі компіляції він перетворюється в JavaScript. В даному коді у нас представлений компонент зі, в якому є текстове значення, яке відображає поточний стан "count"; також є кнопка "Add +1".

Але як зробити дію - так, щоб при натисканні на кнопку відбувалося оновлення стану? Ми можемо написати функцію "onClick", яка оновлює стан за допомогою "setState":

render () {var count = this.state.count; return (<div> <span> Count: <b> {count} </ b> </ span> <button onClick = {() => this.setState ({count: count + 1})}> </ button > </ div>)}

Коли функція "setState" викликається, вся функція "render" викликається ще раз: іншими словами, дія всередині функції "render" ще раз викликає функцію "render". Таким чином, компонент змінюється. React знаходить мінімальний набір зміни в DOM-дереві, коли потрібно оновити сторінку. Ось така проста модель.

Коли ми дивимося на цей код, бачимо, що React - відмінна абстракція. Ми можемо компілювати такий код у все, що завгодно: у нас є React на рівні веб, який переводить функцію "render" з JSX в DOM-дерево, а потім рендерить компонент в нашому дереві.

А що, якщо ми будемо рендерить код в компонент на мобільній платформі? У PhoneGap і подібних ми пишемо програму, яку буде працювати на різних ОС, один раз - в результаті додаток виглядає однаково на різних ОС. Це призводить до зниження рівня досвіду користувача. Це принцип "Write once - run everywhere".

У React Native інша парадигма: ти не пишеш додаток один раз, а один раз вчишся писати додаток, далі пишеш його де завгодно. Це парадигма "Learn once - write anywhere". Іншими словами, навчившись писати в React Native, ви зможете писати програми і для Android, і для iOS, і для інтернету. І, хто знає, може бути, в майбутньому ви зможете писати в React Native для чогось ще.

Рівень рендеринга, який присутній зараз, дуже добре відділений з точки зору логіки. Наприклад, з'являються проекти на React, які дозволяють рендерить в консольні додатки. Тобто ви можете робити на React консольний додаток, що запускається в терміналі і т. Д. Неважливо, що рендерить, - ви вивчили, як це робити, і починаєте писати код.

Чим відрізняється написання компонентів для інтернету і для мобільної платформи? Тим, що при роботі з HTML ми використовуємо елементи <div>, <span>, <img> і т. Д., А React Native пропонує нам елементи як <iew »,« Text »,« Image »,« ScrollView>, <MapView>, <DatePicker> і т. д. Також можна експортувати будь-який потрібний нам компонент: додаткові можна знайти на react.parts/native/

Стилі React Native

Стилі в React Native пишуться за принципом Flexbox, що застосовується в CSS. Якщо хто не знає, Flexbox - підхід до компонування div-елементів. Раніше ми писали "float: left", "float: right", "margin-right" і т. Д. Flexbox ж - нова гнучкіша модель. Саме вона використовується в React Native для написання стилів. Але тут ви їх пишете не в CSS, а в JS - потім вони переводяться на мову, зрозумілу платформі. Припустимо, який-небудь "margin-top" перекладається в зрозумілий для iOS відступ зверху, або в відступ зверху, зрозумілий для Android.

Два способи розділяти платформозавісімую логіку

Ми можемо тримати кодову базу для обох компонентів разом. Але як можна розділяти логіку в коді?

Ось перший спосіб:

if (Plaform.OS === 'android') {// Use an Android toolbar with a search icon} else (Platform.OS === 'ios') {// Use a search bar that looks like iOS} else { // Who knows? }

Тут просто написано, що, якщо платформа - Android, робимо щось специфічне для Android, а якщо iOS - для iOS. Поки що React Native підтримує тільки ці дві ОС, але, хто знає, може, потім з'явиться підтримка і інших платформ ...

Другий спосіб поділу логіки - красивіший:

SearchBar.ios.js SearchBar.android.js

Тут ви просто по-різному називаєте запитувані компоненти, а пакувальник, який збирає додаток, підтягне потрібні вам файли. В кожному файлі будуть знаходитися компоненти, специфічні для даної платформи.

Переваги React Native

• Нативні компоненти і UX: додаток, які ви в результаті отримаєте - не якийсь WebView в нативної оболонці, а справжні нативні компоненти. Це, звичайно ж, підвищує рівень досвіду взаємодії.
• Єдиний воркфлоу і інструменти: неважливо, чи працюєте ви на Android- або iOS-версією - все одно використовуєте одні інструменти.
• З цієї причини - швидкість і простота розробки.
• Обв'язка успадкованого додатки в JS API і гібридні програми: припустимо, у вас вже є готове додаток для iOS, і ви хочете перейти на React Native. Тоді можна обернути нативні компоненти так, щоб вони були доступні в React Native. Так ви можете поступово переходити на React, і виходить гібридне додаток - половина його нативная, а половина - в React, і кілька успадкованих компонентів - в JS API.

В результаті React Native справляється зі своїми завданнями просто прекрасно. Так, наприклад, Facebook Ads Manager для Anroid і iOS написала одна команда всього за три місяці. При цьому для обох ОС повторно використовувалося 85% коду. Це дуже хороший результат.

Все працює просто: вносити зміни в додаток можна дуже швидко. Дуже зручно працювати над дизайном - навіть автори UIkit визнали, що модель, яка використовується в React Native, набагато краще.

Які можуть бути підводні камені? React Native з'явився зовсім недавно, тому платформа подекуди ще сира. Версія для Android з'явилася пізніше, тому для iOS-додатків поки є більше компонентів. Також варто враховувати, що при розгортанні додатки на пристрій користувача потрапить весь JS, тому на рівні презентації не варто тримати секретну бізнес-логіку.

В цілому, платформа може дуже багато чого. Єдине, що я б не став робити на ній, - гри, мабуть, вона під це не заточена. Складні анімації зробити можна, але цьому треба вчитися. А нескладні і середнього рівня складності додатки робляться дуже добре.