Pull to refresh

Comments 18

Картинка отлично показывает третью версию.

Лично для меня react-hot-loader «умер» когда обнаружилось, что теперь надо оборачивать все компоненты их кодом. Я понимаю зачем это нужно, но вот это совсем неудобно. К тому же настройка 3-й версии, мягко говоря, неочевидная (по крайней мере была, когда та только вышла). В итоге отказался от него совсем :(

А что присходит в проде при такой hot() обертке? Оно безболезненно вырезается?
Конечно. В проде от hot-loader не остается ничего.

А насчет оборачивая «их кодом» — имхо — это супер минор.

Фича ради фичи.


  • работает не для всего (только компоненты)
  • работает не всегда (изменения cW/DM)
  • а порой и не работает (для HOC молча падает)

Ради чего все эти ограничения и работа с кодом, который даже близко не похож на то, что будет на проде? Ради экономии одного нажатия F5? И всё это вместо того, чтобы:


  • нормально запроектировать приложение, чтобы F5 восстанавливал его в том же состоянии
  • сделать приложение лёгким и быстро запускающимся.
— работает не для всего (только компоненты)
V3 работал только для компонентов, доступных как переменные. V4 работает на уровне отрендереного React-дерева, в котором НЕ компонент не бывает. А вот то, что hot требует на вход компоненту — как раз логично. Это же базовый строительный блок. И обернуть достаточно «Application»(точку входа). Которая компонента по умолчанию.

— работает не всегда (изменения cW/DM)
К сожалению сложно опять что компонент немного по другому должен старотовать, так как изменение может находиться вне пределов функции. RHL ругнется в консоль, если заметит что-то странное, но обновлять ничего не будет.

— а порой и не работает (для HOC молча падает)
Кто?

— Ради экономии одного нажатия F5?
F5 вы можете сами нажать, а вот для того чтобы привести все приложение в старый стейт — потребуется 5-20 секунд.

— чтобы F5 восстанавливал его в том же состоянии
В общем случае это или не возможно (половине UI сложно прокинуть стейт из redux/mobx), или не нужно (половина элементов UI работают через свои стейты).

Как уже говорилась — версия 4 работает практически для любого приложения. Единственный способ «сломать» — добавить новую ноду перед старыми — следуя дефолтному поведению React все перемаунтит. Решили не бороться со своей стороны.

Некоторые люди считают, что RHL — «вреден». Имхо он позволяет использовать реальный IDE заместо браузерной консоли, чтобы поправить стили или поведение элементов, тем самым позволяя быстрее создать более приятный пользователю look-n-feel.
Тесты — очень вредное явление. Главное потыкать мышкой и убедиться что приложение для пользователя удобно и приятно. То что согластно тестам оно работает правильно — для пользователя не значит ровным счетом ничего.
Я правильно понимаю что если у меня React Router Redux — то нет шансов заставить его работать? Или есть примеры как решать подобную проблему? Сейчас приложение вызывает componentWill/DidMount каждый раз в режиме RHL. ЧЯДНТ?
V4/next? Создай issue, дай сорсы — разберем.
Да V4/next. Как раз почитал статью и перевел проект на него надеясь включить hot reload. Постараюсь в свободное время отловить эту тему и написать тестовый example-проект для пруфа.
Не забывайте про
import { setConfig } from 'react-hot-loader'
setConfig({ logLevel: 'debug' })
Ради экономии одного нажатия F5?

еще экономит нажатия cmd+r.
Умоляю, замените «заместо» на «вместо». Отличная статья, но это режет глаз
Только что применил hot-patch к статье, заменив <Заместо /> на <Вместо />
А что будет если в унитаз поезда на полном ходу бросить лом?
Да, у RHL есть недостатки. Однако про плюсы никто не говорит. «Верстать» компоненты намного приятнее, ибо на каждый чих страница не перезагружается. И бóльшая часть времени разработки в React — это композиция компонентов. Я бы сказал, процентов 90 времени.
Так же, многое зависит от того, как выстроена архитектура самого приложения.

TL;DR: очень сомнительные вайны (местами приемлимые). Вместо нытья — поговорите на Github с мэинтейнерами и откройте пулл реквесты.
Именно так и я поступил — в начале поныл, а потом написал полностью новую версию, с которой ныть уже не надо.

вместо того чтобы мучаться с настройкой RHL, я стараюсь сохранить состояние страницы в URL, localStorage или еще как-то. Чтобы при Crtl+R страница открывалась в том же виде что и до.


Так и мне в девелопменте удобнее, и пользователи, может быть, спасибо скажут.

> Чтобы при Сtrl+R страница открывалась в том же виде что и до.
Вот есть у вас форма — пользователь ввел в нее данные и (!)обновил страницу.
— пользователь видит форму какой она была — пользователь очень рад.
— пользователь видит форму такой какой она _должна_ быть (со старыми данными) — пользователь не рад.
И оба этих варианта имеют право на жизнь. А то тот же самый пользователь не сохранит данные, потому что и так же все нормально.
А где есть два варианта — там есть и три.

Это сильно зависит от формы. Если это большая и сложная форма регистрации, то пользователь будет очень рад, что ему не нужно проходить все шаги заново.


А для разработки формы логин+пароль RHL не нужен, там и с пустыми полями все имплементировать можно. В крайнем случае, можно временно поправить начальный state чтобы получить нужный вид (например, показать сообщение об ошибке), затем откатить перед коммитом.


Для себя я вижу пользу RHL только в составе таких инструментов как storybook, где во-первых руками ничего оборачивать не надо (инструмент сам обернет), а во-вторых, это отдельный от исходников код, поэтому меньше отличий между дев-версией приложения и продакшеном.

В общем надо разработать философию — «зачем нужен RHL», и так чтобы адептам TDD продать можно было.
Sign up to leave a comment.

Articles