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