React PropTypes vs. Flow


101

PropTypes і Flow охоплюють подібні речі, але використовують різні підходи. PropTypes може надавати вам попередження під час виконання, що може бути корисним для швидкого пошуку неправильних відповідей, які надходять із сервера тощо. Однак, Flow здається майбутнім та з такими поняттями, як дженерики - дуже гнучко рішення. Також автодоповнення, запропоновані Nuclide, є великим плюсом для Flow.

Зараз у мене запитання - який найкращий шлях для початку нового проекту. Або може бути хорошим рішенням використовувати і Flow, і PropTypes? Проблема використання обох полягає в тому, що ви пишете багато дублікатів коду. Це приклад програми для музичного плеєра, про який я писав:

export const PlaylistPropType = PropTypes.shape({
    next: ItemPropTypes,
    current: ItemPropTypes,
    history: PropTypes.arrayOf(ItemPropTypes).isRequired
});

export type Playlist = {
    next: Item,
    current: Item,
    history: Array<Item>
};

Обидва визначення в основному містять однакову інформацію, і коли тип даних змінюється, обидва визначення потрібно оновити.

Я знайшов цей плагін Babel для перетворення декларацій типу в PropTypes, що може бути рішенням.


1
Якщо ви хочете розпочати роботу з Flow, спробуйте цей пост: robinwieruch.de/the-soundcloud-client-in-react-redux-flow
Робін Вірух

1
З досвіду використання плагіна, згаданого у питанні, не дуже гарна ідея. Він не підтримує всі типи компонентів, повністю розбитий з React Native станом на v0.39, і, як правило, дуже крихкий. Власник РЕПО реагував на ці питання досить швидко, але, схоже, він втратив інтерес і більше не може покладатися на його підтримку.
Томті

Спробуйте tcomb через плагін Babel для перевірки статичного та тривалого виконання за допомогою Flow та tcomb.
comerc

Відповіді:


81

Через рік після того, як я задав це запитання, я хотів розповісти про те, як переживають цю проблему.

Оскільки Потік розвивався дуже сильно, я почав набирати з ним свою кодову базу і не додав нових визначень PropType. Поки що, я вважаю, що це хороший шлях, оскільки, як було сказано вище, він дозволяє вам не тільки вводити реквізити, але й інші частини коду. Це дуже зручно, наприклад, якщо у вас є копія реквізиту в штаті, яку користувач може змінити. Крім того, автоматичне заповнення IDE - це приголомшливий виграш.

Автоматичні перетворювачі в той чи інший бік насправді не зняли. Отож, для нових проектів я зараз дійсно рекомендую використовувати функцію "Потоку через PropTypes" (якщо ви не хочете робити введення двічі).


який IDE ви використовуєте? Веб-штурм?
sergey.tyan

3
Я використовую Atom з плагіном ide-flowtype.
danielbuechele

вам все ще потрібно propTypes при використанні childContextTypes - stackoverflow.com/questions/42395113 / ...
GKD

3
більше не потрібно використовувати propTypes під час обробки дочірніх контекстів завдяки новому API контексту: reactjs.org/docs/context.html
SteveB

35

Крім обох, що належать до дуже широкого поля перевірки типу, між ними не дуже багато подібності.

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

PropTypes - це перевірка основного типу, яка була зафіксована на React. Він не може перевірити нічого, крім типів реквізиту, що передаються даному компоненту.

Якщо ви хочете більш гнучко перевірити тип тексту для всього свого проекту, то Flow / TypeScript - це відповідний вибір. Поки ви лише передаєте кодовані типи в компоненти, вам не знадобляться PropTypes.

Якщо ви просто хочете перевірити типи опор, тоді не ускладнюйте решту своєї кодової бази та перейдіть до більш простого варіанту.


11
Так, вони сильно відрізняються за рівнем роботи. Однак мета їх використання дуже схожа, я думаю. Але одне, на що ви вказали, є хорошим моментом: Потік давайте вам охоплювати більшу частину кодової бази, тоді як ви обмежуєтесь реквізитом під час використання PropTypes.
danielbuechele

2
Призначення використання дуже схоже, якщо ви використовуєте Flow лише для перевірки типів опор. Одне - це мова, інше - ледве бібліотека.
Дан принц

Повністю згоден з @DanPrince. І я не думаю, що це гарна ідея, щоб перевірити наявність неправильних відповідей з сервера з PropTypes. Краще, якщо у вас є перевірка на це вручну, і ваш інтерфейс користувача відповість належним чином (наприклад, відображає попереджувальне повідомлення), а не просто кидати попередження в консоль.
Ян Такушевич

6
@YanTakushevich Вам потрібно зробити і те, і інше. Прототипи PropType повинні бути відключені під час виробництва, тому вам завжди потрібні перевірки вручну, щоб переконатися, що ваші користувачі мають хороший досвід. Однак PropTypes може бути дуже корисним для попереджень під час розробки під час розробки. Це просто приємна мережа безпеки, щоб не забути нічого.
ndbroadbent

27

Я вважаю, що тут пропущено те, що Flow - це статична перевірка, а PropTypes - це перевірка часу виконання , що означає

  • Потік може перехоплювати помилки вище за течією під час кодування: він теоретично може пропустити деякі помилки, про які ви звичайно не знаєте (якщо, наприклад, ви не реалізували потік у своєму проекті або у випадку глибоко вкладених об'єктів)
  • PropTypes буде ловити їх вниз за течією під час тестування, тому він ніколи не пропускатиме

1
ось виділений плагін для дітлахів
amankkg

15

Спробуйте оголосити тип реквізиту, використовуючи лише Flow. Вкажіть неправильний тип, наприклад, номер замість рядка. Ви побачите, що це буде позначено в коді, який використовує компонент у вашому редакторі потоків даних. Однак це не призведе до збою будь-яких тестів, і ваш додаток все одно буде працювати.

Тепер додайте використання React PropTypes з неправильним типом. Це спричинить збій тестів і буде позначено на консолі браузера під час запуску програми.

Виходячи з цього, здається, що навіть якщо Flow використовується, також слід вказати PropTypes.


Це залежить від того, як проводяться тести, якщо ви користуєтеся знімком тестування джеу, тести не вдасться з недійсними значеннями властивостей.
Олександр Борела

3
Перевага помилки в IDE полягає в тому, що ви бачите її безпосередньо перед тим, як навіть запустити тести.
Том Фенек

Плюс 1 для підходу до поясів і підтяжок.
Девід А. Грей
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.