В то время, как ребята из команд, работающих над Angular, React, мягко, но уверенно пересаживают разработчиков на ES2015, я хотел бы немного рассказать о возможностях использования нового стандарта спецификации с библиотекой Backbone.js. На сегодня основной подход к использованию ES2016 в браузерах один и не зависит от используемого фреймворка/библиотеки. И заключается он в следующем: пишем код на ES2015 и с помощью транспайлера (напр., Babel) получаем код (который и выполняется в браузере) на предыдущем стандарте ES5.
Но как модули, классы и прочие "фишки" из ES2015 использовать в рамках сущностей библиотеки Backbone.js? Об этом речь пойдет под катом.
Прежде всего нам необходимо организовать все файлы моделей, коллекций, представлений и роутов в виде es6 модулей. По моему мнению лучший инструмент для сборки модулей — webpack, если будете использовать в своем проекте его, то вряд ли пожалеете впоследствии. Итак, начнем писать модуль, который будет являться одним из наших представлений:
import $ from 'jquery';
import Backbone from 'backbone';
import _ from 'underscore'; Здесь просто импортировали зависимости, необходимые в данном модуле. Используете другие библиотеки? Поступайте аналогично.
Дальше объявим класс MyCustomView:
class MyCustomView extends Backbone.View {
// our other code
}Как видите созданный класс унаследован от стандартного класса Backbone.View. Кроме этого нам нужно экспортировать MyCustomView, для использования его в других модулях:
class MyCustomView extends Backbone.View {
// our other code
}
export default MyCustomView; Структура модуля готова, осталось добавить созданному классу методы (именно методы, не свойства-функции):
class MyCustomView extends Backbone.View {
initialize() {
}
render() {
}
// our other code
}
export default MyCustomView; Пока все предсказуемо, но мы еще не объявили такие свойства как el, tagName, events. Как будут выглядеть они? Есть 2 подхода: реализовать их объявление через геттеры, либо объявить в методе конструктора, приведу оба примера:
class MyCustomView extends Backbone.View {
get tagName() { return 'div'}
get className() { return 'example' }
get template() { return _.template(myTemplate)}
get events() {
return {
'click': 'sayHelloWorld'
}
}
}используя конструктор, получим:
class MyCustomView extends Backbone.View {
constructor() {
super();
this.tagName = 'div';
this.className = 'example';
this.events = {
'click': 'sayHelloWorld'
};
}
}Аналогичная ситуация будет с атрибутами моделей и коллекций.
К дальнейшему использованию всех "фич" стандарта ES2015 нет никаких препятствий. Вы можете использовать деструктуризацию, строки-шаблоны, итераторы, стрелочные функции, новые типы коллекций, промисы, symbol точно так же, как в других фреймворках/библиотеках, завязки на Backbone.js тут нет.
Например, использование arrow function в методе initialize:
class MyCustomView extends Backbone.View {
initialize() {
setTimeout(() => {this.render()}, 1000);
}
render() {
}
// our other code
}Как видите, внеся минимальные структурные изменения в свой проект, можно легко перейти на ES2015, используя при этом библиотеку Backbone.js. Можно уже сейчас использовать все возможности языка, при этом не разрабатывая на таких бурно развивающихся библиотеках, как React.
Комментарии (93)
EJIqpEP
06.05.2016 13:41У нас на проект сейчас бекбон с марионетом. Проекту 3 года. Пока переписать на что-то более новое не дают. Я поставил вебпак с бабелем и import отлично можно использовать. Для того, чтобы избежать рефакторинга всех вьюх с записью в конструкторе мы просто используем module.exports = Marionette.ItemView.extend({}). Классы это единственное, что мы не используем из ес6 и полет нормальный.
Aries_ua
06.05.2016 13:59+1Многие упускают важную деталь — бизнес логика приложения.
Ни ангуляр, ни реакт, ни бекбон, ни что-то другое не избавит от нее.
Как ни крути, а вам надо будет ее реализовывать. По моим прикидкам это около 90% кода.
Мы используем бекбон, так как мы хотели структурировать код, так как нам нравится.
И сейчас планируем начать переноситься часть функционала на ES6.
Synoptic
08.05.2016 14:58-2Всем любителям протащить Backbone в продакшен в 2016 — прекрасная лекция от hexlet. Просвещайтесь, неучи, типа Aries_ua.
aen
08.05.2016 22:47-2Пока неуч тут только один.
Synoptic
08.05.2016 23:36Уважаемый главный эксперт по бекбону на toster.ru(ну в каждом топике по бекбону там вижу вас, без обид на этот счет). Может быть хоть вы что-то скажете по делу, без понтов и оскорблений, а лучше с примерами кода?
Может быть задачку простейшую решите — https://habrahabr.ru/post/283054/#comment_8887122?
Пока никто не справился, одни слова у всех.aen
08.05.2016 23:46К чему ирония? Видео с Мокевниным приводить вовсе не стоит. Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал. Только смысл всего не в этом. Если вам нравится использовать какой-то иструмент, то используйте, но не надо убеждать кого-то в том, что ложка лучше вилки, а чай лучше кофе. Тем более так эмоционально.
ПС по поводу тостера: я точно также прекрасно могу отвечать на вопросы и про ember.js и про react.js, но как правило на них уже ответили в момент, когда я вопрос читаю.Delphinum
08.05.2016 23:49Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал
Это не имеет значения, видео есть на ютюб, зрители его называют лекцией, на видео серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах. Зрителю не нужно думать, за него уже подумали, нужно только ложить эту инфу себе в голову, пропуская через фильтр собственных убеждений и продвигать полученную идею в массы. Это нормально, так многие делаю первое время.aen
08.05.2016 23:52Но проблему он описал правильно. В реакте проще вообще не думать, а пилить кучу условий, и пусть реакт сам диффы считает.
Delphinum
08.05.2016 23:56А еще React это рендер представления с помощью виртуального DOM, а Backbone это набор структур, для структурирования js проекта (ну чуть больше этого). Но кого здесь это волнует? ))
Synoptic
09.05.2016 00:01Ты когда такие вещи пишешь, делай упоминание автора — toxicmt, а то получается что за спиной подлишь.
Delphinum
09.05.2016 00:04А где в моих словах подлость, дорогой мой? Может быть это «видео есть на ютюб», или это «его называют лекцией», а может это «серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах»? )) Мне кажетсявполне честные слова, и toxicmt не станет их отрицать. Но вам в моем комменте нужно было больше внимания обратить на его вторую часть, тобишь ту, что начинается словами «Зрителю не нужно думать ...».
Synoptic
08.05.2016 23:55+1В видео делается упор не на конкретном решении задачи — ну не серьезно же — он этот код на полчаса написал — а на внимании к проблемам на UI. Backbone — мегавещь, это мой первый SPA-фреймворк. Я проработал с ним несколько лет и вполне готов его и сейчас предпочесть скажем, первому ангуляру. По поводу не нравится — не используйте — я работаю на работе, и меня особо никто не спрашивает, что мне нравится. Есть проект, есть технологический стек, есть задача. Это меня тоже не возмущает, таким образом я несколько лет проработал с Marionette(тоже отличной штукой когда-то).
А вот то, что в середине 2016 года на хабре рекомендуют использовать Backbone для старта проекта — это однозначно из области вредных советов, о чем я и хотел предупредить людей. Хотел предупредить аргументированно и с примерами конкретных сложностей, которые создает Backbone.
Нет цели переубедить — есть цель показать факты — кода с Backbone из за манипуляций DOM писать надо больше и поддерживать его сложнее. Если и вы это будете отрицать, я совсем перестану понимать хабрахабр. Были же адекватные люди, вроде.
aen
09.05.2016 00:02Инструмент должен решать задачи. Потому надо отталиваться от этого. Если react.js решает ваши задачи, то отлично. Если нет, то можно попробовать что-то иное. Брать чистый backbone.js сейчас смысла нет, тут я согласен. Но это просто потому, что его View почти ничего не дает. Но marionette + backbone вполне себе живучий вариант.
Synoptic
09.05.2016 00:08Вполне себе. Но недостатки у него есть, и вполне серьезные, чтобы о них упомянуть в таком топике. Я их подсветил и показал, где их нет. О чем, всего-то, и речь.
Тогда почему я — неуч(я принял это на свой счет)?aen
09.05.2016 00:15Серебряной пули нет. Об этом и в видео сказано. Любой инструмент это в первую очередь компромис из возможностей и ограничений.
Неуч — потому что первым же своим комментарием вы напрочь убили смысл поста.Synoptic
09.05.2016 00:23С первыми комментариями часто так. Если речь об этом, то это так, не умею я писать первые комментарии так, чтобы всем нравилось.
Я подумал, что вы прочитав этот немаленький топик на одной позиции с бабуинами, не понимающими вообще о чем речь, с которыми мне пришлось в процессе общаться, да и вам тоже как вижу. Если это так, то мой мир рухнул и и хабр до конца сошел с ума и пошел, я, пожалуй, обратно в твиттер.Delphinum
09.05.2016 00:32Я подумал, что вы прочитав этот немаленький топик
Если это так, то мой мир рухнул
Кажись у вас мысль началась, но не закончилась ))) Может вам попробовать больше структурировать ваши идеи и мысли, могу предложить для этого Backbone )
Miraage
09.05.2016 11:45Умиляюсь с Ваших геттеров. Все делается намного проще: Babel class properties.
k12th
09.05.2016 12:03А может человек не хочет Babel использовать? Транспиляторы это все-таки не так уж весело.
SerafimArts
14.05.2016 03:27А есть вариант реально на практике использовать ES6 без бабела?
k12th
14.05.2016 13:21Если не стоит задача поддержки IE и Safari, то браузеры уже поддерживают ES2015 лучше, чем Babel: http://kangax.github.io/compat-table/es6/
SerafimArts
14.05.2016 20:47Ничоси! Называется перешёл немного на бекенд и целая революция мимо пролетела, а я даже и не заметил.
С другой стороны только что в консольке проверил:
> class A {} < function class A {} > new A < VM382:2 Uncaught ReferenceError: A is not defined(…)(anonymous function)
Последний блинкоподобный браузер. Это нормально?
k12th
14.05.2016 21:10Вообще странно. Поддержка ES2015 перевалила за 90% в V8 4.8, то есть в Chrome 48. Классы появились уже довольно давно, но в каких-то версиях нормально работали только в strict mode. «Последний блинкоподобный» это какой? А в этой табличке в колонке This browser сколько у вас процентов показывает?
SerafimArts
14.05.2016 22:0393%. Я.Браузер, они не очень сильно отстают, по-этому и сказал что последний (ну да, он не последний, но один из последних, но это не столь критично я думаю).
Предлагаю самостоятельно проверить вышеизложенной мною эксперимент в вашем браузере =)
k12th
14.05.2016 22:05В Chrome 51 работает.
SerafimArts
14.05.2016 22:09О, ну вот как значит даже. Осталось дождаться ФФ и можно уже начинать думать о нативе без бабела. Спасибо!
k12th
14.05.2016 22:12На здоровье. Не забудьте, что в ближайшее время все равно будет нужен es6-module-loader или что-то в этом роде:)
SerafimArts
14.05.2016 22:27Я подозреваю, что лично мне это не грозит, т.к. не могу жить без async\await, а это ES7. Так что бабел ещё на пару лет приживётся. А там, боюсь что и ES8 появится с аналогичными киллерфичами.
Ну т.е. всё как всегда :D
Synoptic
Backbone сейчас — это легаси. Предлагаете и старый код переводить на ES6? Или стартовать новый проект на Backbone, чтобы попользоваться этими фишками?
SerafimArts
Тот же самый пример (ну почти, учитывая специфику паттернов), используя knockout:
Это я ещё не говорю про про заточенные под ES6 либы\фреймы, вроде Аурелии.
Подтверждая слова Synoptic (точнее аргументируя примерами), может стоит уже подумать об апгрейде до Vue\Angular\Aurelia\React\подставить_свой_любимый_фрейм этого, безусловно крутого в прошлые времена фрейма?
alfaslash
Легаси или нет Backbone сейчас, момент неоднозначный и холиварный, и на мой взгляд нет смысла искать ответ на этот вопрос. Я знаю одно — эта библиотека используется на многих сайтах, которые как активно поддерживаются, так и еще разрабатываются. Переписывать существующий код на что-то более прогрессивное или нет — решается в рамках каждого проекта, и зачастую в виду больших трудозатрат этого не происходит. А перевести существующий код на ES6, что бы ощутить все новые возможности языка — задача не такая и сложная, так что да, предлагаю «старый» код переводить на ES6.
Synoptic
>Легаси или нет Backbone сейчас, момент неоднозначный и холиварный, и на мой взгляд нет смысла искать ответ на этот вопрос.
Почему же нет смысла искать? Backbone на сегодняшний день устаревшее решение, делать его основой мало-мальски серьезных проектов нельзя.
>Переписывать существующий код на что-то более прогрессивное или нет — решается в рамках каждого проекта, и зачастую в виду больших трудозатрат этого не происходит.
Сложность этой задачи зависит от размеров проекта. То, что позволено небольшом внутреннем проекте или стартапе, где люди переписывают по десять раз что хотят, на большом проекте никто сделать не позволит, ибо это лишние деньги и неясная цель. На этом моменте разговоры любые разговоры «а давайте перепишем весь код» обычно пресекаются любым адекватным менеджером.
koceg
А что конкретно в BB устарело, на ваш взгляд?
Synoptic
На больших проектах становится очень сложно управлять состояниями. Это даже если брать вместе с Marionette
jacob1237
Состояниями чего? Слоя View? Возмите React, он с Backbone отлично интегрируется
Synoptic
React + Backbone плохое решение за счет отсутствия иммутабельности. От, собсно, Backbone в этом случае остаются только модели и коллекции. Проблему с состояниями View оно не решает.
jacob1237
Иммутабельность по отношению к состояниям View?
На сколько я понимаю JavaScript как язык сам по себе поощряет изменяемость объектов.
Можете раскрыть суть проблемы, с которой столкнулись? Это было бы очень интересно в рамках обмена опытом.
Synoptic
Хорошо описано тут: https://css-tricks.com/learning-react-redux/
Если лень читать, можно ограничиться картинкой. Если вы не сталкивались с проблемой, нарисованной в левой ее части, когда управление связями между кучей компонентов начинает отъедать времени больше, чем написание бизнес-логики, то у вас видимо не такой большой проект.
jacob1237
Спасибо, интересная информация, правда пока что успел только мельком пройтись.
Но правильно ли я понял, что Redux по сути реализует шаблон EventAggregator (http://martinfowler.com/eaaDev/EventAggregator.html)?
Если так, то почему бы не сделать то же самое в Backbone? К тому же в Marionette уже это есть.
Если я все правильно понял, то в чем еще преимущества Redux?
Synoptic
Да, actions из Redux-а это по сути евенты которые ловятся тамошним «EventAggregator»-ом и обрабатываются дальше. Только в Marionette с помощью этого инструмента делаются любые вещи — в коллбеке можно написать и манипуляции с DOM и другие операции, изменяющие состояние приложения напрямую.
В Redux же такие евенты несут лишь название(тип) события типа 'CHECK_FORM_VALUES', и если надо, то некоторую полезную нагрузку извне(значение из поля ввода, типа values: {… } ) по которому потом в специальном месте определяется какой для данного события коллбек надо вызвать.
Все что происходит в таком коллбеке — это какая-то бизнес логика(с помощью чистых функций, это там важно) и, после всех манипуляций фреймворку отдается команда сделать так сказать «патчинг» состояния приложения, в итоге «событие» выглядит всегда примерно так: { type: «CHECK_FORM_VALUES», values: { // some values }}.
Так как все состояние приложении, состояние каждой кнопочки, в Redux хранится в одном большом объекте(специльно немного упрощаю), то пропатчить такое состояние совсем несложно. Как только состояние обновлено, то в дело вступает React со своим крутым diff tree и перерендеривает только то, что надо. Таким образом мы работаем только с данными, не манипулируя DOM. и это удобно.
Можно ли сделать такое на Marionette + React? Ну, думаю, можно :) Но надо ли, когда есть уже готовая хорошая инфраструктура в виде Redux.
AndreyRubankov
> в коллбеке можно написать и манипуляции с DOM
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
ps: а Redux разве еще не устарел?
Aries_ua
Откройте для себя Backbone.Radio
https://github.com/marionettejs/backbone.radio
Вы получите глобальную шину ивентов. Поверьте, это отличная штука, которая делает ваш код несвязанным.
Synoptic
Я давно открыл для себя Backbone.Wreqr, насколько я понимаю что Backbone.Radio это примерно тоже самое? Самого наличия средства глобальной связи между модулями недостаточно чтобы избавиться от высокой связности между модулями.
Aries_ua
Backbone.Radio проще в использовании. Убраны лишние методы.
Кстати marionette переписали в новых версиях на Backbone.Radio.
Можете уточнить, почему недостаточно? Привести кейсы плиз.
Synoptic
Описал отличия между «просто EventAggregator» и условным «EventAggregator в Redux» в этом комментарии своими словами. Чуть повыше есть ссылка на статью, где более научно описываются плюсы. Кратко: шина событий дает слишком много свободы, в коллбеках можно делать что захочется, а надо себя сдерживать.
jacob1237
Делая такое веское заявление, можете пояснить почему Вы считаете что прямо-таки нельзя использовать его? Что предложите взамен, чтобы прям и модели поддерживались и роутинг, и приложение было легковесным?
Synoptic
Использовать-то можно все что угодно. Вопрос в том, что в определенный момент вам станет сложно поддерживать приложение и вы ничего не сможете с этим сделать, так как фреймворк поощряет прямые манипуляции с DOM.
От себя предлагаю React + Redux или что-то типа такого. Лично мне после пары лет использования Backbone/Marionette вполне зашло, такой себе Backbone нового поколения, именно за счет легковесности. Если все нужно из коробки, то angular2, он как раз RC стал.
Само собой, у других фреймворков другие проблемы, но выигрыш в плане удобства поддержки реально ощутимый.
k12th
Пишу на BB давно и много. От прямой манипуляции с DOM отказался сразу, при этом давления со стороны библиотеки не испытал. Так что ничего там не поощряется.
Synoptic
Как вы решаете задачу блокирования 'Send' от неоднократного клика('disabled' аттрибут), когда запрос на сервер уже ушел, но еще не порезолвился? Можете показать код?
k12th
_.debounce
Synoptic
Что — "_.debounce"?
Synoptic
К чему минусы — приведите код, как вы решаете эту задачу? Причем тут _.debounce когда речь о состоянии UI — как вы изменяете состояние кнопки без прямой манипуляции DOM?
Aries_ua
Как один из вариантов, могу привести код. Это простая вью. Просто распишу для примера
// Базовый класс, наследованный от 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 подскажите, как правильно оформить код? Тег
не сработал. Обрамил тегомSynoptic
Эмм… Возможно я не понял примера, но разве метод .button под капотом не работает с DOM напрямую? Если да, то в чем тогда плюсы данного кода?
Aries_ua
Давайте смотреть правде в глаза — все фреймворки работают с 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); } })Вот простой односторонний биндинг. И не нужен тяжеловесный ангуляр для простого кейса.
Но это мелочи, в основном это рендер сложных шаблонов и форм, как пример списки, графики, сложные формы итд.
И здесь уже выходит бизнес логика и шаблонизация.
Synoptic
Да, все работают. Но не все позволяют обходиться без прямых манипуляций DOM, из которых и растет лишний код и проблемы с производительностью.
Кейс с кнопкой — наверное один из самых частых кейсов при разработке UI. Выключенная кнопка — это вариант спиннера, дающего пользователю моментальную реакцию от UI при выполнении асинхронных запросов. Спиннер по вашему — редкий кейс? Это абсолютно не так.
Причем этот кейс — самый простой и при нем не возникает особых проблем. Проблемы начинаются, когда при отправке запроса нам надо заблокировать несколько кнопок, а еще пару инпутов, но некоторые, с виду точно такие же, должны продолжать быть доступными.
При использовании вашего подхода на каждый из этих случаев нам нужна ссылка на каждый элемент(в marionette это будет жирный блок типа ui: { $button1: '.button1', $button2: '.button2',… }), вызов метода на каждый из этих элементов для блокировки и разблокировки.
Что в случае с React/Redux решается просто флагом состояния типа isFormBlocked: true и проверкой непосредственно в шаблоне типа <button {{ isFormBlocked? 'disabled': '' }} — это весь код. Никакого кода для включений-выклчений писать не надо.
Попробуйте хотя бы мысленно решить эту задачу на Backbone и прикиньте сколько кода получится.
Aries_ua
Мне кажется вы принимаете желаемое за действительное. Давайте рассмотрим два примера.
Реакт (набросаю код, который больше схематичный, главное суть)
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); } });Так вот код практически одинаковый. Только в моем случае логика вынесена из шаблона во вью.
Не ради холивара, но поймите ничем особым ангуляр или реакт или еще что либо не лучше и не хуже бекбона. Главное понимать что, как и почему так работает.
Synoptic
Где у вас в вашем примере реализация методов 'enable' или 'disable'? Ведь именно в них происходит манипуляция DOM и именно об этом речь — этот код с реактом писать не надо, а с бекбоном надо.
Aries_ua
Я написал, что код схематичный. Если уж вдаваться в детали, то вот более точная строчка
this.ui.b1.prop('disabled', value);Cути это не меняет. Еще раз подчеркну — ни один фреймворк не спасает от бизнес логики приложения. Если на сайте надо слабать пару форм, вывести пару кнопок и список — это одно. И совсем другое, когда у вас single-page приложение, в котором сотни экранов, десятки компонент итд (CRM+ERP app). Вот тогда вы будете уделать внимание бизнес логике, а не тому — как включить/выключить кнопку — в шаблоне или вьюхе.
Думаю стоит прекращать холивар. К сожалению вы меня ничем не удивили и не привели какого нибудь стоящего примера, что бы я задумался о смене стека технологий.
PS Да реакт клевый, было время я думал на него перевести приложения. Но, стильно/модно/молодежно — оставим для новичков. После глубокого анализа — бенефит был нулевой.
Synoptic
Где я хоть слово сказал про бизнес-логику? Вот комментарий, с которого началась эта длинная дискуссия. Человек утверждает, что не использует манипуляции с DOM в своей работе и Backbone это не поощряет.
Комментарием в ответ я прошу его — не вас — привести пример кода, решающий простейшую типовую задачу без манипуляции с DOM.
Человек сливается, зато в дискуссию со странными примерами кода вписываетесь вы.
Спустя кучу комментариев и просьб с моей стороны показать в конце концов решение задачи без прямой манипуляции DOM я вижу наконец это — код с прямой манипуляцией DOM:
Вопрос — зачем вы потратили кучу моего времени? Вам делать больше нечего?
Aries_ua
Молодой человек — не нервничайте. Ваши доводы о манипуляции с DOM — глупы и неверны. Ниже вам указали, что ни один фреймворк не может не работать с DOM напрямую.
И неважно, пишите вы шаблоне конструкции из условий или в методе обращаетесь к нодам — результат как по затраченному времени и коду — одинаков. На что я вам и указал.
Да, действительно я потратил время, пытаясь вам донести столь очевидный результат.
Synoptic
Я уже понял, что вы настоящий профессионал, вы работаете с мордами для CRM и ERP и понимаете самую суть. Все это правда только на словах. Но еще раз: к чему слова — покажите код! Покажите, что объем кода одинаков?
Вот форма:
Надо при сабмите «Simple form group 3» заблокировать все инпуты в «Simple form group 1» и «Simple form group 5» и подсветить группу. А при сабмите «Simple Group 2» надо заблокировать и подсветить «Simple Group 4».
Это максимально упрощенный сверхтиповой кейс при разработке UI — связь между элементами формы. В реальности завихрения валидации форм гораздо более сложные.
Вот решение на реакте — два флага состояния isGroup3Submitting и isGroup2Submitting в state и сам код:
Это весь код. Покажите, на всеобщее обозрение, решение на Backbone с таким же объемом кода, только без условностей и схематичностей. Покажите, и я признаю свою полнейшую неправоту.
Synoptic
+ обработчики, естественно:
Теперь — весь.
Aries_ua
Вот вам пример формы на бекбон. Выдернул из реального приложения. Только добавил метод для включения/отключения полей.
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); } }); });Мне даже шаблоны не нужны. А вот вы нагородили кучу всего.
Повторюсь, вникните в суть фреймворков.
И еще, поменьше желчи и злобы. Вы не любите бекбон? Не любите на здоровье. Ведь на вкус и цвет все фломастеры разные.
Synoptic
Не надо пример из реального приложения, реализуйте мой пример и сравним.
Aries_ua
А это что по вашему реализовано? Думаете с потолка? Это реально рабочая форма. С методом отключения включения. Или вам надо в ядро бекбона лезть? Так чего уж, давайте тогда и в ядро ангуляра или реакта полезем.
Если вы не умеете готовить бекбон — это ваши личные проблемы.
На этом все. Дальше от вас бессмысленные и бестолковые утверждения.
Больше отвечать не буду.
Synoptic
Ваш тезис — с использованием Backbone и React можно писать код одинаково удобно. Мой тезис — это не так. Я привел элементарный пример, который с React реализуется гораздо проще, чем с Backbone.
Почему вот прямо сейчас бы не показать, как правильно готовить Backbone? Я утрусь, но признаю свою неправоту, если вы сможете это сделать.
А так — много слов и понтов, мало дела.
Delphinum
Вас хватило на слишком долгий монолог, даже странно )))
Synoptic
Это вообще смешно. Вы сами вписались в дискуссию, я и не думал вас чем-то удивлять и вообще собсно к вам не обращался, а только отвечал.
Aries_ua
Смешно как раз то, что приходят люди, поверхностно зная, как работать с фреймворком(ами). Не понимаю сути работы онных.
И да, это комменты к статье, к которой вы написали, что бекбон старье и использовать его нельзя. Я категорично с вами не согласен. Так же я привел аргументы, что ни один мифический фреймворк не лучше другого.
На сем разрешите откланяться, более не буду отнимать у вас время.
Synoptic
Ваши аргументы показали только то, о чем я говорил — на бекбоне при разработке мало-мальски сложного UI нужно писать намного больше кода, чем при использовании более современных технологий. А это значит, что потом это «большее количество кода» кому-то надо будет прочитать, кому-то надо будет покрыть тестами, кому-то надо будет поддерживать. И главное, кому то все это нужно будет оплатить.
Во время приведения ваших аргументов вы тщательным образом пытались манипулировать кодом, чтобы получить нужную вам картинку, намеренно скрывая код о котором шла речь. Во что я ткнул вас носом.
Когда приписываете мне свои влажные фантазии, чтобы выставить себя правым, приводите цитаты, ссылки.
Вот, что я писал про DOM — речь нигде не шла о том, что какой-то фреймворк не работает с DOM. Речь везде шла о том, что во фреймворках старого поколения вроде Backbone программист вынужден работать с DOM.
Выбрали бекбон на свой проект в 2016 году — ну молодцы, поставили своего заказчика на деньги, а кучу программистов, которым потом проект поддерживать — в положение «зачем взяли это говно вместо нормального фреймворка». Это много говорит о вашем профессионализме и мифическом «понимать что, как и почему так работает».
Delphinum
))) покажите фреймворк, который под копотом не работает с DOM?
Жаль что этот ваш комментарий я прочитал последним. Не отвечайте пожалуйста на остальные мои комментарии, думаю диалога у нас с вами не сложится. Спасибо.
Synoptic
Не очень-то и хотелось.
Synoptic
[обращаясь к тем, кто возможно читает тред]
Это яркий пример подмены понятий от нехватки ума.
Я спрашиваю — работает ли с DOM метод .button из приведенного кода, явно написанный кем-то в рамках реализации архитектуры проекта или какой-то фичи? Метод, а не фреймворк. Метод, для особо тупых. Ведь во Backbone такого метода нет.
В ответ — «покажите фреймворк, который под капотом не работает с DOM». Backbone вынуждает работать с DOM не под капотом! Тебе руками этот код придется писать, «погроммист»!
Delphinum
Ой сколько злобы )))
Мистер профи, любой фреймворк от соседа отличается двумя вещами: предлагаемой архитектурой и слоями абстракции. Конечно вы об этом прекрасно знаете, потому ответьте мне сначала на вопрос, какую архитектуру предлагает React, а какую архитектуру предлагает Backbone? После этого вопроса, ответьте, пожалуйста, на вопрос, какие слои абстракции использует React, а какие Backone?
Synoptic
Сначала сформлируйте грамотно вопрос, так как ни Backbone, ни React сами по себе фреймворками не являются. О чем речь, о Backbone+Marionette и React+Redux?
Delphinum
Замечательно что вы это знаете, а чем они являются?
Synoptic
Понятно, еще один любитель потрепать языком. Тебе на тостер.
Delphinum
Ну вот и конец сравнения черного с холодным ) И это хорошо.
Delphinum
Вопрос не ко мне, но возможно мой опыт будет вам полезен (если, конечно, вы не относитесь к разряду ярых хейтеров продукта) — я реализую обертку (особый View) над кнопкой, которая использует в качестве el эту кнопку и навешивает на нее необходимую логику. Связывается кнопка с запросами сервера через внешний View, которым оборачивается (чаще всего) форма и который использует потоковую (stream) модель для взаимодействия с сервером. Аналогично поступает любое другое js решение, просто некоторые оставляют это на плечах разработчика, а некоторые содержат в себе готовые решения.
Delphinum
Разрешать, не есть поощрять. Язык C++ позволяет использовать множественное наследование, что не делает язык C++ устаревшим решением.