#ReactNative

Потрібно мені було зробити свіжу збірку мобільного застосунку для Сінтри, яка наразі в розробницькій паузі. Та React Native там застарів аж майже… на 2 роки! Ціла вічність просто. Звісно ж, зі свіжим XCode 16.3 він не зібрався (чотири місяці тому на 16.2 ще збирався.)

Це не вперше з ним таке — десь в коді залежностей на С++ вилазить несумісність, яку, звісно, згодом виправляють, але тільки для нещодавніх версій.

Я чесно кажучи не знаю, чому воно так нестабільно себе поводить. Чи це всі проєкти на C++ так, чи то через розробників, чи то тому, що RN не типовий продукт на iOS та потребує особливих обходів.

Почав оновлювати… а там така круговерть. Спочатку RN, потім Node, потім просто React, Babel, React Native Navigation… В якийсь момент Yarn почав відвалюватися за браком памʼяті, що є поганим знаком.

Зрештою зʼясувалося, що оновлення взагалі не можливе, бо React Native Navigation не підтримує поки навіть найстарішу версію RN, яка була виправлена для XCode 16.3. Фініш?

Наступною ідеєю я вирішив збирати проєкт на GitHub Actions, на старій версії macOS. Це майже вийшло, але застопорився на підписі застосунку, там теж щось треба багато переробляти (бо я завжди збирав та підписував локально).

І тут несподівано знайшов, що стару версію XCode можна поставити й на мою машину! Осьо сайт Xcode Releases, де є посилання навіть на доісторичні версії. Тобто встановив собі поруч /Applications/Xcode 16.2.app та на ньому, ще після кількох чомусь потрібних виправлень все зібралося.

Гадаю, Apple ускладнили розробникам життя тим, що XCode встановлюється з App Store та через це неочевидно, що старі версії взагалі можна знайти. А виявляється, навіть asdf-xcodes є!

Як висновок… певно, треба навчитися зберігати всі залежності будь-якого проєкту, а можливо, разом із тулчейном. Місце на диску значно дешевше нервів.

React Native відрізняється від React тільки набором компонентів. Тож замість div буде View, замість p - Text тощо. Ці компоненти створюють справжній набір відповідних “рідних” компонент пристрою. (А якщо так подумати, то div та p в React для вебу теж не “є” тегами HTML, а тільки створюють вузли DOM - поведінка така сама.)

Все інше, що ти знаєш з React, продовжує працювати й в React Native. Власні компоненти, хуки, контексти, модель, Redux, Reselect, Axios, і так далі. Також це звичайний JS/TS. (Хіба що тулчейн буде особливий - Metro замість всього, до чого звикли в вебі.)

В React Native власна модель викладки, яка майже повторює Flexbox. Та вона нам дуже корисна, бо мобільні пристрої бувають всяких різних розмірів. В мене взагалі так вийшло, що я цей флексбокс вивчив саме в контексті React Native, в той час, як на вебі користувався старішими рішеннями. Сподобалось! На мобільний пристрій дизайнити екрани якось легше, бо вони тебе заздалегідь обмежують та нема такого відчуття великого порожнього аркуша, як на вебі.

В React Native замість CSS є структури стилів, вони нагадують CSS, але не повторюють. Також немає великої потреби в окремих таблицях стилів, на відміну від вебу можна їх без проблем задавати прямо в компоненті. В мене найкраще виходило, коли я створював шар презентаційних компонент, в яких сиділи всі стилі. (Схожим підходом і для вебу роблять.)

Треба серйозно ставитися до навігації. На відміну від вебу, де застосунок React є єдиною сторінкою, RN доводиться оперувати рідними екранами пристрою. Тому відразу варто роздивитися інструкцію по навігації та робити правильну архітектуру. А не повторювати підходи з вебу, де в тебе просто замість одного екрану малюється інший.

Майже всі мислимі можливості покриті бібліотеками. Завжди всі питають “наскільки легко інтегрувати то чи інше”. Практично завжди відповідь “на то є бібліотека!” Все те, що не входить в базовий комплект, можна знайти на NPM, наприклад: react-native-iap для підтримки покупок.