Comments 98
UFO landed and left these words here

Тот же самый пример (ну почти, учитывая специфику паттернов), используя 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.
UFO landed and left these words here
UFO landed and left these words here
Состояниями чего? Слоя View? Возмите React, он с Backbone отлично интегрируется
UFO landed and left these words here
Иммутабельность по отношению к состояниям View?
На сколько я понимаю JavaScript как язык сам по себе поощряет изменяемость объектов.
Можете раскрыть суть проблемы, с которой столкнулись? Это было бы очень интересно в рамках обмена опытом.
UFO landed and left these words here
Спасибо, интересная информация, правда пока что успел только мельком пройтись.

Но правильно ли я понял, что Redux по сути реализует шаблон EventAggregator (http://martinfowler.com/eaaDev/EventAggregator.html)?
Если так, то почему бы не сделать то же самое в Backbone? К тому же в Marionette уже это есть.

Если я все правильно понял, то в чем еще преимущества Redux?
UFO landed and left these words here
> в коллбеке можно написать и манипуляции с DOM

«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)

Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)

ps: а Redux разве еще не устарел?
Откройте для себя Backbone.Radio

https://github.com/marionettejs/backbone.radio

Вы получите глобальную шину ивентов. Поверьте, это отличная штука, которая делает ваш код несвязанным.
UFO landed and left these words here
Backbone.Radio проще в использовании. Убраны лишние методы.
Кстати marionette переписали в новых версиях на Backbone.Radio.

Можете уточнить, почему недостаточно? Привести кейсы плиз.
UFO landed and left these words here
Backbone на сегодняшний день устаревшее решение, делать его основой мало-мальски серьезных проектов нельзя.

Делая такое веское заявление, можете пояснить почему Вы считаете что прямо-таки нельзя использовать его? Что предложите взамен, чтобы прям и модели поддерживались и роутинг, и приложение было легковесным?
UFO landed and left these words here
Пишу на BB давно и много. От прямой манипуляции с DOM отказался сразу, при этом давления со стороны библиотеки не испытал. Так что ничего там не поощряется.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Как один из вариантов, могу привести код. Это простая вью. Просто распишу для примера

// Базовый класс, наследованный от 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 подскажите, как правильно оформить код? Тег не сработал. Обрамил тегом
UFO landed and left these words here
Давайте смотреть правде в глаза — все фреймворки работают с 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);
   }
})


Вот простой односторонний биндинг. И не нужен тяжеловесный ангуляр для простого кейса.

Но это мелочи, в основном это рендер сложных шаблонов и форм, как пример списки, графики, сложные формы итд.
И здесь уже выходит бизнес логика и шаблонизация.
UFO landed and left these words here
Мне кажется вы принимаете желаемое за действительное. Давайте рассмотрим два примера.

Реакт (набросаю код, который больше схематичный, главное суть)
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);
   }
});


Так вот код практически одинаковый. Только в моем случае логика вынесена из шаблона во вью.

Не ради холивара, но поймите ничем особым ангуляр или реакт или еще что либо не лучше и не хуже бекбона. Главное понимать что, как и почему так работает.
UFO landed and left these words here
Я написал, что код схематичный. Если уж вдаваться в детали, то вот более точная строчка

this.ui.b1.prop('disabled', value);


Cути это не меняет. Еще раз подчеркну — ни один фреймворк не спасает от бизнес логики приложения. Если на сайте надо слабать пару форм, вывести пару кнопок и список — это одно. И совсем другое, когда у вас single-page приложение, в котором сотни экранов, десятки компонент итд (CRM+ERP app). Вот тогда вы будете уделать внимание бизнес логике, а не тому — как включить/выключить кнопку — в шаблоне или вьюхе.

Думаю стоит прекращать холивар. К сожалению вы меня ничем не удивили и не привели какого нибудь стоящего примера, что бы я задумался о смене стека технологий.

PS Да реакт клевый, было время я думал на него перевести приложения. Но, стильно/модно/молодежно — оставим для новичков. После глубокого анализа — бенефит был нулевой.
UFO landed and left these words here
Молодой человек — не нервничайте. Ваши доводы о манипуляции с DOM — глупы и неверны. Ниже вам указали, что ни один фреймворк не может не работать с DOM напрямую.

И неважно, пишите вы шаблоне конструкции из условий или в методе обращаетесь к нодам — результат как по затраченному времени и коду — одинаков. На что я вам и указал.

Да, действительно я потратил время, пытаясь вам донести столь очевидный результат.
UFO landed and left these words here
UFO landed and left these words here
Вот вам пример формы на бекбон. Выдернул из реального приложения. Только добавил метод для включения/отключения полей.

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);
        }

    });

});



Мне даже шаблоны не нужны. А вот вы нагородили кучу всего.
Повторюсь, вникните в суть фреймворков.

И еще, поменьше желчи и злобы. Вы не любите бекбон? Не любите на здоровье. Ведь на вкус и цвет все фломастеры разные.
UFO landed and left these words here
А это что по вашему реализовано? Думаете с потолка? Это реально рабочая форма. С методом отключения включения. Или вам надо в ядро бекбона лезть? Так чего уж, давайте тогда и в ядро ангуляра или реакта полезем.

Если вы не умеете готовить бекбон — это ваши личные проблемы.

На этом все. Дальше от вас бессмысленные и бестолковые утверждения.
Больше отвечать не буду.
UFO landed and left these words here
UFO landed and left these words here
Смешно как раз то, что приходят люди, поверхностно зная, как работать с фреймворком(ами). Не понимаю сути работы онных.

И да, это комменты к статье, к которой вы написали, что бекбон старье и использовать его нельзя. Я категорично с вами не согласен. Так же я привел аргументы, что ни один мифический фреймворк не лучше другого.

На сем разрешите откланяться, более не буду отнимать у вас время.
UFO landed and left these words here
Сейчас задумался о переходе с Backbone + Marionette на что-то другое. То, что умеет интеллектуально рендерить и обновлять DOM-дерево в сложных SPA.
Так вот. Ваша ветка комментариев мне изрядно помогла в определении.
Увидел шаблон на реакте с этими условиями, либо у вас Bad Practice, либо это так заведено. Но вставка в шаблон условия на классы, условия на атрибуты влечет за собой множество проблем при возвращении к коду через месяц или другим разработчиком.
В данном случае разбиение на триггеры и обращение к ui конкретной view, а так же очеловечивание названий функций куда упрощают восприятие подобных сложных форм.

А избегать перерендеривания вьюхи целиком можно путем дробления ее на дочерние, а не создавая огромные темплейты с такими формами.

Почему у вас эта форма не представлена в коллекции? Почему темплейт этой формы не состоит из одного блока?
но разве метод .button под капотом не работает с DOM напрямую?

))) покажите фреймворк, который под копотом не работает с DOM?

Жаль что этот ваш комментарий я прочитал последним. Не отвечайте пожалуйста на остальные мои комментарии, думаю диалога у нас с вами не сложится. Спасибо.
UFO landed and left these words here
UFO landed and left these words here
Ой сколько злобы )))
Мистер профи, любой фреймворк от соседа отличается двумя вещами: предлагаемой архитектурой и слоями абстракции. Конечно вы об этом прекрасно знаете, потому ответьте мне сначала на вопрос, какую архитектуру предлагает React, а какую архитектуру предлагает Backbone? После этого вопроса, ответьте, пожалуйста, на вопрос, какие слои абстракции использует React, а какие Backone?
UFO landed and left these words here
UFO landed and left these words here
Вопрос не ко мне, но возможно мой опыт будет вам полезен (если, конечно, вы не относитесь к разряду ярых хейтеров продукта) — я реализую обертку (особый View) над кнопкой, которая использует в качестве el эту кнопку и навешивает на нее необходимую логику. Связывается кнопка с запросами сервера через внешний View, которым оборачивается (чаще всего) форма и который использует потоковую (stream) модель для взаимодействия с сервером. Аналогично поступает любое другое js решение, просто некоторые оставляют это на плечах разработчика, а некоторые содержат в себе готовые решения.
так как фреймворк поощряет прямые манипуляции с DOM

Разрешать, не есть поощрять. Язык C++ позволяет использовать множественное наследование, что не делает язык C++ устаревшим решением.
У нас на проект сейчас бекбон с марионетом. Проекту 3 года. Пока переписать на что-то более новое не дают. Я поставил вебпак с бабелем и import отлично можно использовать. Для того, чтобы избежать рефакторинга всех вьюх с записью в конструкторе мы просто используем module.exports = Marionette.ItemView.extend({}). Классы это единственное, что мы не используем из ес6 и полет нормальный.
Я бы переписал на реакт с редуксом так как на проекте важна индексация, а реакт позволяет легко рендерить все на бекенде. Да и опыт написания проекта на редуксе уже есть
Многие упускают важную деталь — бизнес логика приложения.
Ни ангуляр, ни реакт, ни бекбон, ни что-то другое не избавит от нее.

Как ни крути, а вам надо будет ее реализовывать. По моим прикидкам это около 90% кода.

Мы используем бекбон, так как мы хотели структурировать код, так как нам нравится.

И сейчас планируем начать переноситься часть функционала на ES6.
Огромное вам человеческое спасибо за трюк с get tagName() { return 'div'}.
Нагуглите Бена Маккормика, у него на эту тему есть позабористей статья.
UFO landed and left these words here
UFO landed and left these words here
К чему ирония? Видео с Мокевниным приводить вовсе не стоит. Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал. Только смысл всего не в этом. Если вам нравится использовать какой-то иструмент, то используйте, но не надо убеждать кого-то в том, что ложка лучше вилки, а чай лучше кофе. Тем более так эмоционально.

ПС по поводу тостера: я точно также прекрасно могу отвечать на вопросы и про ember.js и про react.js, но как правило на них уже ответили в момент, когда я вопрос читаю.
Он привел пример отвратительного решения задачи, да и сам сказал, что толком с Backbone не работал

Это не имеет значения, видео есть на ютюб, зрители его называют лекцией, на видео серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах. Зрителю не нужно думать, за него уже подумали, нужно только ложить эту инфу себе в голову, пропуская через фильтр собственных убеждений и продвигать полученную идею в массы. Это нормально, так многие делаю первое время.
Но проблему он описал правильно. В реакте проще вообще не думать, а пилить кучу условий, и пусть реакт сам диффы считает.
А еще React это рендер представления с помощью виртуального DOM, а Backbone это набор структур, для структурирования js проекта (ну чуть больше этого). Но кого здесь это волнует? ))
UFO landed and left these words here
А где в моих словах подлость, дорогой мой? Может быть это «видео есть на ютюб», или это «его называют лекцией», а может это «серьезный дяденька рассказывает группе серьезных людей об очень серьезных вещах»? )) Мне кажетсявполне честные слова, и toxicmt не станет их отрицать. Но вам в моем комменте нужно было больше внимания обратить на его вторую часть, тобишь ту, что начинается словами «Зрителю не нужно думать ...».
UFO landed and left these words here
Инструмент должен решать задачи. Потому надо отталиваться от этого. Если react.js решает ваши задачи, то отлично. Если нет, то можно попробовать что-то иное. Брать чистый backbone.js сейчас смысла нет, тут я согласен. Но это просто потому, что его View почти ничего не дает. Но marionette + backbone вполне себе живучий вариант.
UFO landed and left these words here
Серебряной пули нет. Об этом и в видео сказано. Любой инструмент это в первую очередь компромис из возможностей и ограничений.

Неуч — потому что первым же своим комментарием вы напрочь убили смысл поста.
UFO landed and left these words here
UFO landed and left these words here
Я подумал, что вы прочитав этот немаленький топик

Если это так, то мой мир рухнул

Кажись у вас мысль началась, но не закончилась ))) Может вам попробовать больше структурировать ваши идеи и мысли, могу предложить для этого Backbone )
UFO landed and left these words here
UFO landed and left these words here
А может человек не хочет Babel использовать? Транспиляторы это все-таки не так уж весело.
А то есть геттеры с классами он будет не через Babel использовать? :)
Вылезайте из танка (или танчиков), дивный новый мир: http://kangax.github.io/compat-table/es6/
Не надо ёрничать. Я прекрасно знаю эту таблицу и в курсе всего.
В новом дивном мире всё равно остаётся как минимум IE10-IE11 в плане пользовательской базы.
Ёрничать начали вы. А вы считаете, что я такой идиот что взял и забыл про проклятье всех веб-разработчиков? Отнюдь. Просто есть проекты, где поддержка IE не нужна. Есть корпоративные интранеты, где стандарт это Chrome. Есть какие-то проекты, которые в старых IE смотреть смысла нет, потому что там не работает что-то еще, например WebAudio. Есть проекты с заделом на будущее, которые планируется зарелизить когда IE11 постигнет судьба IE6.
Есть корпоративные интранеты, где стандарт это Chrome.

А есть корпоративные интранеты которые ложили на хром и хотят видеть IE

примеры из практики:
Coca-colla — проект был 1,5 года назад основной браузер который они хотели видеть IE9
один американский банк — проект сейчас — вот зимой только отказались от IE8 потому что они наконец сделали апгрейд софта в своем парке

ЗЫ. не всем везет разрабатывать под хром
ЗЫЫ если что, я без наездов (а то тут в коментариях у некоторых кипят эмоции), просто вы как-то слишком категорично сказали что даже в корпоративнов секторе уже все радужно.
Вопрос был можно или нельзя использовать классы без Babel. Ответ — в некоторых типах проектов можно. Согласны?

А как оно обычно в корпоративных интранетах устроено — это я отлично знаю, просто есть прекрасные исключения.
Если не стоит задача поддержки 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%. Я.Браузер, они не очень сильно отстают, по-этому и сказал что последний (ну да, он не последний, но один из последних, но это не столь критично я думаю).


Предлагаю самостоятельно проверить вышеизложенной мною эксперимент в вашем браузере =)

О, ну вот как значит даже. Осталось дождаться ФФ и можно уже начинать думать о нативе без бабела. Спасибо!

На здоровье. Не забудьте, что в ближайшее время все равно будет нужен es6-module-loader или что-то в этом роде:)

Я подозреваю, что лично мне это не грозит, т.к. не могу жить без async\await, а это ES7. Так что бабел ещё на пару лет приживётся. А там, боюсь что и ES8 появится с аналогичными киллерфичами.


Ну т.е. всё как всегда :D

Only those users with full accounts are able to leave comments. Log in, please.