Comments 98
Тот же самый пример (ну почти, учитывая специфику паттернов), используя knockout:
class MyCustomViewModel {
sayHelloWorld() {
// do something
}
}
///
ko.applyBindings(new MyCustomViewModel, document.querySelector('.example'));<div class="example" data-bind="click: sayHelloWorld"></div>Это я ещё не говорю про про заточенные под ES6 либы\фреймы, вроде Аурелии.
Подтверждая слова Synoptic (точнее аргументируя примерами), может стоит уже подумать об апгрейде до Vue\Angular\Aurelia\React\подставить_свой_любимый_фрейм этого, безусловно крутого в прошлые времена фрейма?
Легаси или нет Backbone сейчас, момент неоднозначный и холиварный, и на мой взгляд нет смысла искать ответ на этот вопрос. Я знаю одно — эта библиотека используется на многих сайтах, которые как активно поддерживаются, так и еще разрабатываются. Переписывать существующий код на что-то более прогрессивное или нет — решается в рамках каждого проекта, и зачастую в виду больших трудозатрат этого не происходит. А перевести существующий код на ES6, что бы ощутить все новые возможности языка — задача не такая и сложная, так что да, предлагаю «старый» код переводить на ES6.
А что конкретно в BB устарело, на ваш взгляд?
Состояниями чего? Слоя View? Возмите React, он с Backbone отлично интегрируется
Иммутабельность по отношению к состояниям View?
На сколько я понимаю JavaScript как язык сам по себе поощряет изменяемость объектов.
Можете раскрыть суть проблемы, с которой столкнулись? Это было бы очень интересно в рамках обмена опытом.
На сколько я понимаю JavaScript как язык сам по себе поощряет изменяемость объектов.
Можете раскрыть суть проблемы, с которой столкнулись? Это было бы очень интересно в рамках обмена опытом.
Спасибо, интересная информация, правда пока что успел только мельком пройтись.
Но правильно ли я понял, что Redux по сути реализует шаблон EventAggregator (http://martinfowler.com/eaaDev/EventAggregator.html)?
Если так, то почему бы не сделать то же самое в Backbone? К тому же в Marionette уже это есть.
Если я все правильно понял, то в чем еще преимущества Redux?
Но правильно ли я понял, что Redux по сути реализует шаблон EventAggregator (http://martinfowler.com/eaaDev/EventAggregator.html)?
Если так, то почему бы не сделать то же самое в Backbone? К тому же в Marionette уже это есть.
Если я все правильно понял, то в чем еще преимущества Redux?
> в коллбеке можно написать и манипуляции с DOM
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
ps: а Redux разве еще не устарел?
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
ps: а Redux разве еще не устарел?
Откройте для себя Backbone.Radio
https://github.com/marionettejs/backbone.radio
Вы получите глобальную шину ивентов. Поверьте, это отличная штука, которая делает ваш код несвязанным.
https://github.com/marionettejs/backbone.radio
Вы получите глобальную шину ивентов. Поверьте, это отличная штука, которая делает ваш код несвязанным.
Backbone на сегодняшний день устаревшее решение, делать его основой мало-мальски серьезных проектов нельзя.
Делая такое веское заявление, можете пояснить почему Вы считаете что прямо-таки нельзя использовать его? Что предложите взамен, чтобы прям и модели поддерживались и роутинг, и приложение было легковесным?
Пишу на BB давно и много. От прямой манипуляции с DOM отказался сразу, при этом давления со стороны библиотеки не испытал. Так что ничего там не поощряется.
_.debounce
Как один из вариантов, могу привести код. Это простая вью. Просто распишу для примера
Код примитивный, но показывает, что с домом можно не работать напрямую. При этом все под контролем.
PS подскажите, как правильно оформить код? Тег
// Базовый класс, наследованный от Marrionette.ItemView
var class = Base.View.extend({
// Определяем элементы с которыми будем работать
ui: {
send: '.css_class_button'
},
// Биндим события для определенных элементов
events: {
'click @ui.send': 'onClick'
},
// Определяем метод клик для кнопки
onClick: function() {
// Блокируем кнопку перед отправкой данных на сервер
this.ui.button.button('loading');
API({...})
.then(function() {
// разблокируем кнопку
this.ui.button.button('reset');
});
}
});
Код примитивный, но показывает, что с домом можно не работать напрямую. При этом все под контролем.
PS подскажите, как правильно оформить код? Тег
не сработал. Обрамил тегом Давайте смотреть правде в глаза — все фреймворки работают с DOM. Все так или иначе, но или изменяют ноды, или перерендивают шаблоны. Другого не существует.
В ангуляре вы изменили значение и фреймворк пройдется и изменит DOM. Реакт поступает похожим образом.
В бекбоне через проперть ui вы получаете доступ к элементам контекста вьюхи. Подчеркну именно вьюхи. Случайным образом вы не получите список кнопок по классу, если к примеру у вас больше одного инстанса вьюхи в DOM.
Кейс с блокировкой кнопки, скажем так, мелкий и редкий кейс. Решается довольно просто, создается компонент кнопки, который вы будете использовать в других вьюхах. Похожий кейс к примеру вывести инфу из модели при изменении какого нибудь значения.
Пример:
Вот простой односторонний биндинг. И не нужен тяжеловесный ангуляр для простого кейса.
Но это мелочи, в основном это рендер сложных шаблонов и форм, как пример списки, графики, сложные формы итд.
И здесь уже выходит бизнес логика и шаблонизация.
В ангуляре вы изменили значение и фреймворк пройдется и изменит DOM. Реакт поступает похожим образом.
В бекбоне через проперть ui вы получаете доступ к элементам контекста вьюхи. Подчеркну именно вьюхи. Случайным образом вы не получите список кнопок по классу, если к примеру у вас больше одного инстанса вьюхи в DOM.
Кейс с блокировкой кнопки, скажем так, мелкий и редкий кейс. Решается довольно просто, создается компонент кнопки, который вы будете использовать в других вьюхах. Похожий кейс к примеру вывести инфу из модели при изменении какого нибудь значения.
Пример:
var cls = Base.View.extend({
ui: {
text: '.css_class_text'
},
initialize: function(options) {
this.listenTo(options.model, 'change:name', this.onChangeName.bind(this));
},
onChangeName: function(model, value) {
this.ui.text.html(value);
}
})
Вот простой односторонний биндинг. И не нужен тяжеловесный ангуляр для простого кейса.
Но это мелочи, в основном это рендер сложных шаблонов и форм, как пример списки, графики, сложные формы итд.
И здесь уже выходит бизнес логика и шаблонизация.
Мне кажется вы принимаете желаемое за действительное. Давайте рассмотрим два примера.
Реакт (набросаю код, который больше схематичный, главное суть)
Теперь тоже на BB
Так вот код практически одинаковый. Только в моем случае логика вынесена из шаблона во вью.
Не ради холивара, но поймите ничем особым ангуляр или реакт или еще что либо не лучше и не хуже бекбона. Главное понимать что, как и почему так работает.
Реакт (набросаю код, который больше схематичный, главное суть)
React.createClass({
isFormBlocked: false,
metho1: function() {
this.isFormBlocked = true;
},
metho2: function() {
this.isFormBlocked = false;
},
render: function() {
return (
<button class="btn"{{ isFormBlocked? 'disabled': '' }}>
<button class="btn"{{ isFormBlocked? 'disabled': '' }}>
<button class="btn"{{ isFormBlocked? 'disabled': '' }}>
);
}
});
Теперь тоже на BB
Base.View.extend({
ui: {
b1: 'btn1',
b2: 'btn2',
b3: 'btn3'
},
toggle: function(value) {
this.ui.b1[value ? 'enable' : 'disable']();
this.ui.b2[value ? 'enable' : 'disable']();
this.ui.b3[value ? 'enable' : 'disable']();
},
metho1: function() {
this.toggle(true);
},
metho2: function() {
this.toggle(false);
}
});
Так вот код практически одинаковый. Только в моем случае логика вынесена из шаблона во вью.
Не ради холивара, но поймите ничем особым ангуляр или реакт или еще что либо не лучше и не хуже бекбона. Главное понимать что, как и почему так работает.
Я написал, что код схематичный. Если уж вдаваться в детали, то вот более точная строчка
Cути это не меняет. Еще раз подчеркну — ни один фреймворк не спасает от бизнес логики приложения. Если на сайте надо слабать пару форм, вывести пару кнопок и список — это одно. И совсем другое, когда у вас single-page приложение, в котором сотни экранов, десятки компонент итд (CRM+ERP app). Вот тогда вы будете уделать внимание бизнес логике, а не тому — как включить/выключить кнопку — в шаблоне или вьюхе.
Думаю стоит прекращать холивар. К сожалению вы меня ничем не удивили и не привели какого нибудь стоящего примера, что бы я задумался о смене стека технологий.
PS Да реакт клевый, было время я думал на него перевести приложения. Но, стильно/модно/молодежно — оставим для новичков. После глубокого анализа — бенефит был нулевой.
this.ui.b1.prop('disabled', value);
Cути это не меняет. Еще раз подчеркну — ни один фреймворк не спасает от бизнес логики приложения. Если на сайте надо слабать пару форм, вывести пару кнопок и список — это одно. И совсем другое, когда у вас single-page приложение, в котором сотни экранов, десятки компонент итд (CRM+ERP app). Вот тогда вы будете уделать внимание бизнес логике, а не тому — как включить/выключить кнопку — в шаблоне или вьюхе.
Думаю стоит прекращать холивар. К сожалению вы меня ничем не удивили и не привели какого нибудь стоящего примера, что бы я задумался о смене стека технологий.
PS Да реакт клевый, было время я думал на него перевести приложения. Но, стильно/модно/молодежно — оставим для новичков. После глубокого анализа — бенефит был нулевой.
Молодой человек — не нервничайте. Ваши доводы о манипуляции с DOM — глупы и неверны. Ниже вам указали, что ни один фреймворк не может не работать с DOM напрямую.
И неважно, пишите вы шаблоне конструкции из условий или в методе обращаетесь к нодам — результат как по затраченному времени и коду — одинаков. На что я вам и указал.
Да, действительно я потратил время, пытаясь вам донести столь очевидный результат.
И неважно, пишите вы шаблоне конструкции из условий или в методе обращаетесь к нодам — результат как по затраченному времени и коду — одинаков. На что я вам и указал.
Да, действительно я потратил время, пытаясь вам донести столь очевидный результат.
Вот вам пример формы на бекбон. Выдернул из реального приложения. Только добавил метод для включения/отключения полей.
Мне даже шаблоны не нужны. А вот вы нагородили кучу всего.
Повторюсь, вникните в суть фреймворков.
И еще, поменьше желчи и злобы. Вы не любите бекбон? Не любите на здоровье. Ведь на вкус и цвет все фломастеры разные.
define([
'settings',
'core/form'
], function(settings, CoreForm) {
var parent = CoreForm.views.Form;
return parent.extend({
fields: {
title: {
type: 'select',
req: false,
label: gettext('Title')
},
firstName: {
type: 'input',
req: true,
label: gettext('First Name')
},
lastName: {
type: 'input',
req: true,
label: gettext('Name')
},
dateOfBirth: {
type: 'date',
format: settings.format.date,
req: false,
label: gettext('Date Of Birth')
},
phoneNumber: {
type: 'input',
req: true,
label: gettext('Phone Number')
}
},
setDisabled: function(value) {
this.ui.title.prop('disabled', value);
this.ui.dateOfBirth.prop('disabled', value);
this.ui.phoneNumber.prop('disabled', value);
}
});
});
Мне даже шаблоны не нужны. А вот вы нагородили кучу всего.
Повторюсь, вникните в суть фреймворков.
И еще, поменьше желчи и злобы. Вы не любите бекбон? Не любите на здоровье. Ведь на вкус и цвет все фломастеры разные.
А это что по вашему реализовано? Думаете с потолка? Это реально рабочая форма. С методом отключения включения. Или вам надо в ядро бекбона лезть? Так чего уж, давайте тогда и в ядро ангуляра или реакта полезем.
Если вы не умеете готовить бекбон — это ваши личные проблемы.
На этом все. Дальше от вас бессмысленные и бестолковые утверждения.
Больше отвечать не буду.
Если вы не умеете готовить бекбон — это ваши личные проблемы.
На этом все. Дальше от вас бессмысленные и бестолковые утверждения.
Больше отвечать не буду.
Смешно как раз то, что приходят люди, поверхностно зная, как работать с фреймворком(ами). Не понимаю сути работы онных.
И да, это комменты к статье, к которой вы написали, что бекбон старье и использовать его нельзя. Я категорично с вами не согласен. Так же я привел аргументы, что ни один мифический фреймворк не лучше другого.
На сем разрешите откланяться, более не буду отнимать у вас время.
И да, это комменты к статье, к которой вы написали, что бекбон старье и использовать его нельзя. Я категорично с вами не согласен. Так же я привел аргументы, что ни один мифический фреймворк не лучше другого.
На сем разрешите откланяться, более не буду отнимать у вас время.
Сейчас задумался о переходе с Backbone + Marionette на что-то другое. То, что умеет интеллектуально рендерить и обновлять DOM-дерево в сложных SPA.
Так вот. Ваша ветка комментариев мне изрядно помогла в определении.
Увидел шаблон на реакте с этими условиями, либо у вас Bad Practice, либо это так заведено. Но вставка в шаблон условия на классы, условия на атрибуты влечет за собой множество проблем при возвращении к коду через месяц или другим разработчиком.
В данном случае разбиение на триггеры и обращение к ui конкретной view, а так же очеловечивание названий функций куда упрощают восприятие подобных сложных форм.
А избегать перерендеривания вьюхи целиком можно путем дробления ее на дочерние, а не создавая огромные темплейты с такими формами.
Почему у вас эта форма не представлена в коллекции? Почему темплейт этой формы не состоит из одного блока?
Так вот. Ваша ветка комментариев мне изрядно помогла в определении.
Увидел шаблон на реакте с этими условиями, либо у вас Bad Practice, либо это так заведено. Но вставка в шаблон условия на классы, условия на атрибуты влечет за собой множество проблем при возвращении к коду через месяц или другим разработчиком.
В данном случае разбиение на триггеры и обращение к ui конкретной view, а так же очеловечивание названий функций куда упрощают восприятие подобных сложных форм.
А избегать перерендеривания вьюхи целиком можно путем дробления ее на дочерние, а не создавая огромные темплейты с такими формами.
Почему у вас эта форма не представлена в коллекции? Почему темплейт этой формы не состоит из одного блока?
но разве метод .button под капотом не работает с DOM напрямую?
))) покажите фреймворк, который под копотом не работает с DOM?
Жаль что этот ваш комментарий я прочитал последним. Не отвечайте пожалуйста на остальные мои комментарии, думаю диалога у нас с вами не сложится. Спасибо.
Ой сколько злобы )))
Мистер профи, любой фреймворк от соседа отличается двумя вещами: предлагаемой архитектурой и слоями абстракции. Конечно вы об этом прекрасно знаете, потому ответьте мне сначала на вопрос, какую архитектуру предлагает React, а какую архитектуру предлагает Backbone? После этого вопроса, ответьте, пожалуйста, на вопрос, какие слои абстракции использует React, а какие Backone?
Мистер профи, любой фреймворк от соседа отличается двумя вещами: предлагаемой архитектурой и слоями абстракции. Конечно вы об этом прекрасно знаете, потому ответьте мне сначала на вопрос, какую архитектуру предлагает React, а какую архитектуру предлагает Backbone? После этого вопроса, ответьте, пожалуйста, на вопрос, какие слои абстракции использует React, а какие Backone?
Вопрос не ко мне, но возможно мой опыт будет вам полезен (если, конечно, вы не относитесь к разряду ярых хейтеров продукта) — я реализую обертку (особый View) над кнопкой, которая использует в качестве el эту кнопку и навешивает на нее необходимую логику. Связывается кнопка с запросами сервера через внешний View, которым оборачивается (чаще всего) форма и который использует потоковую (stream) модель для взаимодействия с сервером. Аналогично поступает любое другое js решение, просто некоторые оставляют это на плечах разработчика, а некоторые содержат в себе готовые решения.
так как фреймворк поощряет прямые манипуляции с DOM
Разрешать, не есть поощрять. Язык C++ позволяет использовать множественное наследование, что не делает язык C++ устаревшим решением.
У нас на проект сейчас бекбон с марионетом. Проекту 3 года. Пока переписать на что-то более новое не дают. Я поставил вебпак с бабелем и import отлично можно использовать. Для того, чтобы избежать рефакторинга всех вьюх с записью в конструкторе мы просто используем module.exports = Marionette.ItemView.extend({}). Классы это единственное, что мы не используем из ес6 и полет нормальный.
Многие упускают важную деталь — бизнес логика приложения.
Ни ангуляр, ни реакт, ни бекбон, ни что-то другое не избавит от нее.
Как ни крути, а вам надо будет ее реализовывать. По моим прикидкам это около 90% кода.
Мы используем бекбон, так как мы хотели структурировать код, так как нам нравится.
И сейчас планируем начать переноситься часть функционала на ES6.
Ни ангуляр, ни реакт, ни бекбон, ни что-то другое не избавит от нее.
Как ни крути, а вам надо будет ее реализовывать. По моим прикидкам это около 90% кода.
Мы используем бекбон, так как мы хотели структурировать код, так как нам нравится.
И сейчас планируем начать переноситься часть функционала на ES6.
Огромное вам человеческое спасибо за трюк с
get tagName() { return 'div'}.
Пока неуч тут только один.
К чему ирония? Видео с Мокевниным приводить вовсе не стоит. Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал. Только смысл всего не в этом. Если вам нравится использовать какой-то иструмент, то используйте, но не надо убеждать кого-то в том, что ложка лучше вилки, а чай лучше кофе. Тем более так эмоционально.
ПС по поводу тостера: я точно также прекрасно могу отвечать на вопросы и про ember.js и про react.js, но как правило на них уже ответили в момент, когда я вопрос читаю.
ПС по поводу тостера: я точно также прекрасно могу отвечать на вопросы и про ember.js и про react.js, но как правило на них уже ответили в момент, когда я вопрос читаю.
Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал
Это не имеет значения, видео есть на ютюб, зрители его называют лекцией, на видео серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах. Зрителю не нужно думать, за него уже подумали, нужно только ложить эту инфу себе в голову, пропуская через фильтр собственных убеждений и продвигать полученную идею в массы. Это нормально, так многие делаю первое время.
Но проблему он описал правильно. В реакте проще вообще не думать, а пилить кучу условий, и пусть реакт сам диффы считает.
А где в моих словах подлость, дорогой мой? Может быть это «видео есть на ютюб», или это «его называют лекцией», а может это «серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах»? )) Мне кажетсявполне честные слова, и toxicmt не станет их отрицать. Но вам в моем комменте нужно было больше внимания обратить на его вторую часть, тобишь ту, что начинается словами «Зрителю не нужно думать ...».
Инструмент должен решать задачи. Потому надо отталиваться от этого. Если react.js решает ваши задачи, то отлично. Если нет, то можно попробовать что-то иное. Брать чистый backbone.js сейчас смысла нет, тут я согласен. Но это просто потому, что его View почти ничего не дает. Но marionette + backbone вполне себе живучий вариант.
Вы что, с ума сошли?! Он же под копотом с DOM работает!
Серебряной пули нет. Об этом и в видео сказано. Любой инструмент это в первую очередь компромис из возможностей и ограничений.
Неуч — потому что первым же своим комментарием вы напрочь убили смысл поста.
Неуч — потому что первым же своим комментарием вы напрочь убили смысл поста.
Я подумал, что вы прочитав этот немаленький топик
Если это так, то мой мир рухнул
Кажись у вас мысль началась, но не закончилась ))) Может вам попробовать больше структурировать ваши идеи и мысли, могу предложить для этого Backbone )
Ув. Delphinum не спорьте с ним. Это бессмысленно. Не кормите троля.
Умиляюсь с Ваших геттеров. Все делается намного проще: Babel class properties.
А может человек не хочет Babel использовать? Транспиляторы это все-таки не так уж весело.
А то есть геттеры с классами он будет не через Babel использовать? :)
Вылезайте из танка (или танчиков), дивный новый мир: http://kangax.github.io/compat-table/es6/
Не надо ёрничать. Я прекрасно знаю эту таблицу и в курсе всего.
В новом дивном мире всё равно остаётся как минимум IE10-IE11 в плане пользовательской базы.
В новом дивном мире всё равно остаётся как минимум IE10-IE11 в плане пользовательской базы.
Ёрничать начали вы. А вы считаете, что я такой идиот что взял и забыл про проклятье всех веб-разработчиков? Отнюдь. Просто есть проекты, где поддержка IE не нужна. Есть корпоративные интранеты, где стандарт это Chrome. Есть какие-то проекты, которые в старых IE смотреть смысла нет, потому что там не работает что-то еще, например WebAudio. Есть проекты с заделом на будущее, которые планируется зарелизить когда IE11 постигнет судьба IE6.
Есть корпоративные интранеты, где стандарт это Chrome.
А есть корпоративные интранеты которые ложили на хром и хотят видеть IE
примеры из практики:
Coca-colla — проект был 1,5 года назад основной браузер который они хотели видеть IE9
один американский банк — проект сейчас — вот зимой только отказались от IE8 потому что они наконец сделали апгрейд софта в своем парке
ЗЫ. не всем везет разрабатывать под хром
ЗЫЫ если что, я без наездов (а то тут в коментариях у некоторых кипят эмоции), просто вы как-то слишком категорично сказали что даже в корпоративнов секторе уже все радужно.
А есть вариант реально на практике использовать ES6 без бабела?
Если не стоит задача поддержки IE и Safari, то браузеры уже поддерживают ES2015 лучше, чем Babel: http://kangax.github.io/compat-table/es6/
Ничоси! Называется перешёл немного на бекенд и целая революция мимо пролетела, а я даже и не заметил.
С другой стороны только что в консольке проверил:
> class A {}
< function class A {}
> new A
< VM382:2 Uncaught ReferenceError: A is not defined(…)(anonymous function) Последний блинкоподобный браузер. Это нормально?
Вообще странно. Поддержка ES2015 перевалила за 90% в V8 4.8, то есть в Chrome 48. Классы появились уже довольно давно, но в каких-то версиях нормально работали только в strict mode. «Последний блинкоподобный» это какой? А в этой табличке в колонке This browser сколько у вас процентов показывает?
93%. Я.Браузер, они не очень сильно отстают, по-этому и сказал что последний (ну да, он не последний, но один из последних, но это не столь критично я думаю).
Предлагаю самостоятельно проверить вышеизложенной мною эксперимент в вашем браузере =)
Sign up to leave a comment.
Использование стандарта ES2015 в рамках библиотеки Backbone.js