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

Проведіть через те, що реально відбувається при виклику нативного методу з JS — у старій і новій архітектурі.

На старому мості виклик серіалізується в JSON, стає в чергу, батчується, асинхронно надсилається на нативний бік, виконується, і результат серіалізується назад — кожен перехід коштує часу, і нічого не синхронно. З JSI TurboModule — реальний C++-обʼєкт, на який JS зберігає пряме посилання; виклик методу йде через C++-байндинг без JSON-серіалізації й без черги, і може бути синхронним, якщо це потрібно. Плата — складність: написати TurboModule як слід означає мати справу з кодогенерацією і C++, тоді як модуль на старому мості був ближчим до звичайного JS-подібного клейового коду.

`FlatList` на кілька сотень рядків гальмує під час скролу — як підступитися?

Спершу профілювати — профайлер Flipper/React DevTools чи вбудований perf monitor покаже, вартість у JS (ре-рендери, важкий renderItem) чи в нативному потоці (layout, зображення). Далі перевірити базове: стабільний keyExtractor, React.memo на рядку, щоб зміна стану батька не каскадувалася на кожен рядок, і відсутність інлайнових стрілкових функцій та обʼєктних літералів у пропсах рядка. Якщо проблема в смиканні layout, getItemLayout позбавляє від проходу вимірювання на елемент, а якщо вузьке місце — сам список за великого масштабу, перехід на FlashList часто прагматичніший за подальшу ручну настройку FlatList.

Фічі потрібна можливість, якої React Native не надає — як дістатися нативного коду, і що доведеться дублювати?

Пишете нативний модуль — реалізацію на Swift/Objective-C для iOS і на Kotlin/Java для Android, — з однаковою сигнатурою методу з обох боків, бо JS викликає один JS-фейсинг API, який має розвʼязатися в реальну реалізацію на тій платформі, де виконується. Пропуск однієї платформи означає, що застосунок там впаде або мовчки нічого не зробить, тож обидві реалізації мають насправді робити те саме, а не просто мати однакову назву. Тестувати треба на реальному пристрої чи симуляторі кожної платформи, а не довіряти тому, що «воно зібралося».

Як надійно обробляти deep link, включно з холодним стартом?

Зареєструвати URL-схему чи universal link/app link у нативному конфізі (Info.plist / AndroidManifest.xml) і в конфізі linking навігатора, зіставивши патерни URL з екранами й параметрами. Складність — холодний старт: якщо застосунок не був запущений, під час старту треба перевірити Linking.getInitialURL() і використати його для початкового стану навігації, бо слухач події Linking сам по собі ловить лише посилання, що прийшли, поки застосунок уже відкритий. Universal links додатково потребують файли associated-domains / assetlinks.json, розміщені на вашому домені, щоб ОС довіряла застосунку обробку цього URL замість відкриття браузера.

У чому різниця між OTA-оновленням і релізом через стор, і коли що використовувати?

OTA-оновлення (CodePush, Expo Updates) надсилає новий JS-бандл прямо на встановлені застосунки без ревʼю в сторі, і користувачі отримують його при наступному запуску чи фоновій перевірці — добре для суто JS-багфіксів і змін контенту. Усе, що зачіпає нативний код — новий нативний модуль, додавання дозволу, оновлення нативної залежності, — взагалі не входить до JS-бандла, тож OTA цього не доставить; потрібна справжня збірка й відправка в стор. Правила Apple прямо забороняють OTA «суттєво змінювати основне призначення застосунку», тож команда, що покладається на OTA понад швидкі фікси, ризикує акаунтом у сторі, а не лише оновленням.