Питання на співбесіді React Native

У чому різниця між props і state у React Native?

Props — дані лише для читання, передані батьківським компонентом, і володіє ними той, хто їх передав; state — локальний стан компонента, що змінюється з часом через useState або useReducer. Компонент, який отримав однакові props двічі без зміни state, має рендерити однаковий результат — саме це робить props передбачуваними. Передавання сеттерів вниз через props («підняття стану») — стандартний спосіб дати дочірньому компоненту викликати зміну state, яким він не володіє.

Що таке JSX і у що він насправді компілюється?

JSX — синтаксичний цукор для викликів React.createElement: <View style={styles.box}>{text}</View> перетворюється на дерево обʼєктів-елементів, а не на реальні DOM-вузли, бо DOM у нативному застосунку немає. Трансформація Babel перетворює теги на виклики функцій ще до виконання JS, тож JSX — зручність часу збірки, а не рантайм-фіча. У React Native ці обʼєкти-елементи врешті описують ієрархію нативних view, а не HTML.

Що роблять `useState` і `useEffect`, і коли запускається ефект?

useState дає компоненту частину стану та сеттер, який під час виклику запускає ре-рендер; useEffect виконує побічний ефект після коміту рендера і перезапускається лише тоді, коли змінилося щось із масиву залежностей. Забута залежність — найчастіша причина застарілих замикань: ефект продовжує посилатися на значення з того рендера, в якому був створений. Порожній масив залежностей означає «запустити один раз при монтуванні», а відсутність масиву — «запускати після кожного рендера».

Як влаштована стилізація в React Native і чому Flexbox поводиться інакше, ніж у вебі?

CSS тут немає — стилі це JS-обʼєкти, створені через StyleSheet.create і під капотом відображені на властивості нативних view. Flexbox лишається рушієм розкладки, але flexDirection за замовчуванням column, а не row, каскаду CSS немає, а одиниці — безрозмірні density-independent пікселі, а не px/em/rem. Відсотки в ширині, flex: 1 для заповнення простору, що залишився, і justifyContent/alignItems для вирівнювання покривають більшість реальних розкладок.

Як працює навігація через React Navigation, і що додає deep linking?

React Navigation представляє застосунок як дерево навігаторів — stack, tab, drawer, — кожен екран реєструється під іменем, а navigation.navigate('Screen', params) перемикає між ними, зберігаючи стек історії для жесту «назад». Deep linking зіставляє зовнішню URL-схему чи universal link із конкретним екраном і параметрами, тож push-сповіщення або посилання з вебу може одразу відкрити, скажімо, екран деталей замовлення, а не головний екран застосунку. Правильна реалізація вимагає обробки і холодного старту (застосунок ще не запущено), і теплого повернення за посиланням у вже працюючому застосунку.

Що таке міст (bridge), і чим він відрізняється від JSI та New Architecture?

У старій архітектурі JS і нативний код не поділяють памʼять — вони спілкуються через міст, асинхронну, батчовану, JSON-серіалізовану чергу повідомлень, через що кожен нативний виклик несе вартість серіалізації та затримку. JSI (JavaScript Interface) замінює це прямими C++-байндингами: JS зберігає посилання на нативні обʼєкти й викликає їхні методи синхронно, без серіалізації. New Architecture будується поверх JSI: TurboModules замінюють нативні модулі, а Fabric замінює старий UI-менеджер, обидва спілкуються з нативним кодом напряму замість черги через міст.

Як не дати довгому `FlatList` гальмувати?

Дати кожному елементу стабільний keyExtractor, обгорнути компонент рядка в React.memo, щоб ре-рендер батька не перемальовував кожен рядок, і уникати інлайнових функцій та обʼєктних літералів у renderItem, бо нове посилання на кожен рендер зводить мемоізацію нанівець. getItemLayout пропускає прохід вимірювання, якщо висота рядка фіксована, а windowSize/initialNumToRender/removeClippedSubviews міняють памʼять на плавність скролу. Для дуже великих або складних списків FlashList від Shopify вирішує те саме завдання з меншою ручною настройкою.

У чому реальні відмінності між збіркою під iOS та Android у React Native?

Safe area, поведінка клавіатури й стилізація тіней (shadow*-пропси на iOS проти elevation на Android) розходяться настільки, що піксель-у-піксель паритет вимагає платформо-специфічного коду через Platform.select або розширення файлів .ios.js/.android.js. Дозволи, налаштування push-сповіщень і ліміти фонових завдань підпорядковані правилам кожної платформи — обмеження фонового виконання в Android і суворіший ревʼю App Store в iOS це різні обмеження, а не просто різні API. Нативний модуль, написаний під одну платформу, потребує повноцінного аналога на Swift/Objective-C та Kotlin/Java, перш ніж запрацює на обох.

Як насправді виходить реліз — до чого тут Metro, OTA-оновлення й ревʼю в сторі?

Metro бандлить і роздає JS під час розробки та пакує його в бінарник застосунку для релізу; він не є частиною того, що отримують користувачі, це лише інструмент збірки. Сервіси OTA-оновлень на кшталт CodePush чи Expo Updates надсилають новий JS-бандл прямо на встановлені застосунки без ревʼю App Store чи Play Store, що швидко для багфіксів, але прямо заборонено для всього, що змінює нативний код або виходить за межі того, що стор вважає «просто контентом». Нативні зміни — новий нативний модуль, дозвіл, оновлення SDK — завжди вимагають повної збірки й нової відправки в стор, тож команда живе на двох швидкостях: OTA для суто JS-фіксів, релізи через стор для всього нативного.