Comments 8
Где это используете? Что побудило строить такой самолёт заместо простой перезагрузки страницы, например? Или хотя бы просьбы перезагрузить страницу, как это сделано в веб версии телеграма и много ещё где?
В данный момент очень плотно работаю с React (разделяю монолитное Rails приложение на клиент-сервер), многие формы, такие, как форма оплаты, например, имеют несколько шагов. Очень удобно не заполнять/прокликивать первые N шагов, а просто применять новые изменения к нужному шагу «на лету». Так же просто довольно удобно работать — на одном мониторе браузер, на ноутбуке текстовый редактор. Нажал cmd + s — в ту же секунду увидел результат. Ну и вёрстка становится в разы веселее :)
По поводу веб версии телеграмма и пр. — это иное. Моё решение исключительно для разработчиков, дабы увеличить удовольствие от разработки и сделать сам процесс ещё увлекательнее, но никак не изменить поведение программы. Моей целью было реализовать react-hot-loader для browserify
По поводу веб версии телеграмма и пр. — это иное. Моё решение исключительно для разработчиков, дабы увеличить удовольствие от разработки и сделать сам процесс ещё увлекательнее, но никак не изменить поведение программы. Моей целью было реализовать react-hot-loader для browserify
Добрый день.
Совсем недавно делал похожее для mithril.js — тоже хотелось обновлений в реалтайме без перезагрузки страницы, чтобы не терять состояние. Я тогда за основу взял livereload, т.к. в целом он уже много чего умеет — у него есть сервер, клиент, интеграция с grunt/gulp и их watch, живое обновление css и полная перезагрузка страницы при других изменениях. Еще к нему можно писать плагины — например перехватить обновление js файлов (или какого-то конкретного — в вашем случае diff-файла) и дальше делать с ним что угодно. Если я ничего не упустил, то это позволит упростить ваше решение, убрав сервер, коммуникации по вебсокетам и, возможно, отслеживание изменений.
Совсем недавно делал похожее для mithril.js — тоже хотелось обновлений в реалтайме без перезагрузки страницы, чтобы не терять состояние. Я тогда за основу взял livereload, т.к. в целом он уже много чего умеет — у него есть сервер, клиент, интеграция с grunt/gulp и их watch, живое обновление css и полная перезагрузка страницы при других изменениях. Еще к нему можно писать плагины — например перехватить обновление js файлов (или какого-то конкретного — в вашем случае diff-файла) и дальше делать с ним что угодно. Если я ничего не упустил, то это позволит упростить ваше решение, убрав сервер, коммуникации по вебсокетам и, возможно, отслеживание изменений.
Здравствуйте!
Все вотчеры работают поверх fsevents, в моём случае это библиотека, которую использует watchify, например. Интеграция с grunt/gulp при работе с browserify? Ну не знаю, лично я не люблю ни gulp ни grunt, т.к. на мой взягляд большую часть настроек можно прописать в том же package.json в разделе scripts. Вот отличная статья на эту тему.
browserify и работа с css — разные вещи.
Именно этого я и стараюсь избежать
В моем случае вы можете делать то же самое для JS файлов. В данный момент я работаю над «частичной перезагрузкой» бандла, как это делает webpack, уже совсем скоро будет возможность получать отдельно измененные файлы и патчи.
К сожалению, не всё так просто: во-первых, меня не устраивает, что проект платный. Я люблю open source и не хочу строить своё решение поверх платного проекта. Во-вторых, сервер и коммуникации по веб-сокетам это не уберет. Вернее, можно, конечно, заменить сокеты long-polling'ом, но смысла в этом я не вижу, в данный момент все популярные браузеры поддерживают сокеты. Что касается сервера — заменить — не значит убрать. Как вы думаете, работает livereload? Он точно так же создает свой сервер и наблюдает за файлами, а различные плагины к хрому и script-коды и т.п. просто выступают в качестве клиента (у меня это browserify transforms).
у него есть сервер, клиент, интеграция с grunt/gulp и их watch
Все вотчеры работают поверх fsevents, в моём случае это библиотека, которую использует watchify, например. Интеграция с grunt/gulp при работе с browserify? Ну не знаю, лично я не люблю ни gulp ни grunt, т.к. на мой взягляд большую часть настроек можно прописать в том же package.json в разделе scripts. Вот отличная статья на эту тему.
живое обновление css
browserify и работа с css — разные вещи.
и полная перезагрузка страницы при других изменениях
Именно этого я и стараюсь избежать
Еще к нему можно писать плагины — например перехватить обновление js файлов (или какого-то конкретного — в вашем случае diff-файла) и дальше делать с ним что угодно
В моем случае вы можете делать то же самое для JS файлов. В данный момент я работаю над «частичной перезагрузкой» бандла, как это делает webpack, уже совсем скоро будет возможность получать отдельно измененные файлы и патчи.
Если я ничего не упустил, то это позволит упростить ваше решение, убрав сервер, коммуникации по вебсокетам и, возможно, отслеживание изменений.
К сожалению, не всё так просто: во-первых, меня не устраивает, что проект платный. Я люблю open source и не хочу строить своё решение поверх платного проекта. Во-вторых, сервер и коммуникации по веб-сокетам это не уберет. Вернее, можно, конечно, заменить сокеты long-polling'ом, но смысла в этом я не вижу, в данный момент все популярные браузеры поддерживают сокеты. Что касается сервера — заменить — не значит убрать. Как вы думаете, работает livereload? Он точно так же создает свой сервер и наблюдает за файлами, а различные плагины к хрому и script-коды и т.п. просто выступают в качестве клиента (у меня это browserify transforms).
Зачем, если есть webpack?
Бытует мнение, что webpack лучше browserify. Честно говоря, я его не разделяю. Мне нравится browserify и я хочу, чтобы люди, разделяющую мою точку зрения, имели схожий DX с пользователями webpack. Возможно, Вам будет интересно прочитать пост от substack'а (создателя browserify) «Browserify для пользователей webpack»
А с транспилерами как интеграция? С babel и jsx, в частности.
Sign up to leave a comment.
Обновление React компонентов с сохранением состояния в режиме реального времени для Browserify