Комментарии 23
Почему Backbone, а не Flux? Рассматривали ли Вы его?
Рассматривал конечно. Flux как архитектура, в принципе может быть применима и в Rocket. В Rocket есть эмиттер, есть хранилища. При рассмотрении фреймверков на основе Flux лично мне не совсем понравилась громоздкость некоторых реализаций. А Бекбон сам по себе отличный фреймверк, с хорошими возможностями наследования, с кучей полезных методов, также как необходимая зависимость lodash в большинстве проектов будет полезна. Да и все это в совокупности весит немного, что тоже плюс.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Оп, вовремя подвернулись под руку.
Как раз искал, кого бы помучать вопросом на эту тему: есть ли улучшения по перформансу при использовании react как шаблонизатора? По сравнению с классическими решениями
Как раз искал, кого бы помучать вопросом на эту тему: есть ли улучшения по перформансу при использовании react как шаблонизатора? По сравнению с классическими решениями
Почему вы рассматриваете реакт, как средство для увеличения производительности приложения? Если только для этого — есть более быстрые инструменты. React — это вовсе не про скорость, а про удобство написания и тестирования компонентов. Скорость — просто одно из достоинств реализации. Ну и ждите 0.14, там есть некоторые улучшения в этом плане.
Киллер фичей Реакта является скорость рендеринга, так как в Реакте используется виртуальный дом и мощный алгоритм сравнения измененных участков внутри компоненты, что позволяет обновлять только тот узел, где данные модели реально изменились. Есть куча сравнительных статей Реакта и прочих фреймверков, где подробно рассматриваются его преимущества в плане производительности. Лично я не проводил детальные исследования этого вопроса, как по мне, лучше не перегружать фронтэнд данными, не выводить в одну въюху коллекцию на тысячи элементов, это даже с точки зрения юзабилити будет не удобно и я уверен любой фреймверк с большим количеством данных будет тормозить.
и я уверен любой фреймверк с большим количеством данных будет тормозить
Слепая уверенность до добра не доводит: facebook.github.io/fixed-data-table/example-object-data.html
Можете смело найти не один десяток статей о том что «скорость» не одно из преимуществ React'а.
На хабре ребята уже писали про облегченную версию Бэкбона "Exoskeleton". Там оставлена поддержка только для современных браузеров.
Попросили сделать такой же скелетон, но с Ангуляром. Если кому то будет нужно, пользуйтесь на здоровье
Отличия — менеджер пакетов bower, убран browserify, sinon
Angular MEAN
Отличия — менеджер пакетов bower, убран browserify, sinon
Angular MEAN
Коллекции и модели от Backbone — это очень хорошо, но совершенно не про React. Мы у себя на проекте скрестили эти две технологии и теперь мучаемся. Лучше бы сразу на flux'е всё делали.
Проблема: Передаём в компонент коллекцию или только модель, меняем модель (коллекцию), сохраняем.
Ничего нигде не перерендеривается. React.state ничего не узнаёт о том что изменилась модель, потому что модель — это не плоская сущность.
Конечно можно использовать миксины вроде react-backbone, что проблему как бы решает, но в реальности только усугубляем положение, скрещивая две совершенно разных методики.
Вывод: Не используйте React и Backbone вместе, если вы вдруг решили это сделать прочитав статью. Поддержка этого решения дорого вам обойдётся.
Проблема: Передаём в компонент коллекцию или только модель, меняем модель (коллекцию), сохраняем.
Ничего нигде не перерендеривается. React.state ничего не узнаёт о том что изменилась модель, потому что модель — это не плоская сущность.
Конечно можно использовать миксины вроде react-backbone, что проблему как бы решает, но в реальности только усугубляем положение, скрещивая две совершенно разных методики.
Вывод: Не используйте React и Backbone вместе, если вы вдруг решили это сделать прочитав статью. Поддержка этого решения дорого вам обойдётся.
Вот мой пример работы с React, Reflux и Backbone.
github.com/VladimirPal/react-flux-backbone
Проблемы описанной вами не наблюдается.
github.com/VladimirPal/react-flux-backbone
Проблемы описанной вами не наблюдается.
>> Поддержка этого решения дорого вам обойдётся.
Если не react-backbone, то можно обойтись добавлением чего-нибудь такого в компонент:
Если не react-backbone, то можно обойтись добавлением чего-нибудь такого в компонент:
... = React.createClass({
...
componentDidMount: function() {
this.props.model.on('change', function() {
if (this.isMounted()) this.forceUpdate();
}.bind(this));
},
...
});
В любом случае — вам придётся скрещивать две разные методики и дублировать состояния в модели и в компоненте. Так же вам придётся отказаться от некоторых встроенных плюшек моделей и коллекций.
Я не говорю о том что невозможно скрестить эти две библиотеки, я говорю о том что чем больше проект, тем больше будет возникать проблем и сложностей с их поддержкой. И идея flux сразу писать кучу кода уже не выглядит настолько безумной
Я не говорю о том что невозможно скрестить эти две библиотеки, я говорю о том что чем больше проект, тем больше будет возникать проблем и сложностей с их поддержкой. И идея flux сразу писать кучу кода уже не выглядит настолько безумной
Понимаю, было бы здорово, если бы React изначально умел обращаться с Backbone. Мне всё же кажется, что это небольшая плата за совместимость двух полезных вещей, которые разрабатывались независимо. Такая прослойка при желании прячется и не фигурирует в основном коде.
Дублировать ничего не нужно, а события коллекций обрабатываются тем же образом.
Поделитесь, пожалуйста, опытом, если вы сталкивались с действительными проблемами такого подхода, которые усугубляют положение. Он будет полезен не только мне.
Поддерживаю перфекционизм, когда на него есть время. Но в данном случае это пока единственное, от чего пришлось отказаться.
Дублировать ничего не нужно, а события коллекций обрабатываются тем же образом.
Поделитесь, пожалуйста, опытом, если вы сталкивались с действительными проблемами такого подхода, которые усугубляют положение. Он будет полезен не только мне.
Поддерживаю перфекционизм, когда на него есть время. Но в данном случае это пока единственное, от чего пришлось отказаться.
Browserify не совсем DI…
Вы создали самый странный микс технологий для React из тех что я видел… React + Backbone + react-router + browserify…
Во-первых, если пишите Flux (а делать большое приложение на React и без Flux — странно), то модели и коллекции из Backbone — не лучшее решение. Когда хранилища являются простыми объектами — жить проще.
Во-вторых, если уж сильно так хочется backbone — хорошо, но зачем react-router? В backbone уже есть роутер. Только лишние зависимости тащите…
Ну в наконец — большинство ребят из коммьюнити React используют webpack (я говорю про тех, кто развивает React, кто выступает на конфах), а значит и большая масса пользователей тоже скорее всего на webpack сидит. Но ок, дело вкуса.
Во-первых, если пишите Flux (а делать большое приложение на React и без Flux — странно), то модели и коллекции из Backbone — не лучшее решение. Когда хранилища являются простыми объектами — жить проще.
Во-вторых, если уж сильно так хочется backbone — хорошо, но зачем react-router? В backbone уже есть роутер. Только лишние зависимости тащите…
Ну в наконец — большинство ребят из коммьюнити React используют webpack (я говорю про тех, кто развивает React, кто выступает на конфах), а значит и большая масса пользователей тоже скорее всего на webpack сидит. Но ок, дело вкуса.
Добавил в закладки чтоб подсматривать гульп задачи по деплою на фтп и созданию док, спасибо)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
React boilerplate — Rocket React