Comments 29
Синтаксис «Усы», наверное стоило перевести как синтаксис библиотеки «Mustache» ={
А разве он не появился раньше в Django (а, может быть, ещё раньше в Ruby On Rails, с которым я не знаком)?
Почему всегда сравнивают jquery лапшу (без отделения бизнес логики от представления) и фреймворки? Можно так же элегантно писать использую jquery. Просто нужно вынести data за описание интерфейса. Создать какой-нибудь объект, который будет отвечать за бизнес логику и подписать на изменения его данных. Тут идея в другом, jquery это императивный подход описания интерфейса, а все фреймворки в основном используют декларативный подход
На мой взгляд статья выглядит не сравненим фреймворков как таковых, а попыткой показать что как раз декларативный подход (просто автор предпочитает vue) понятнее чем императивный (на примере jquery)
Ну так декларативный на то и декларативный. И тут уже не важно какой фреймворк выбирать.
var eventMixin = {
	on: function (eventName, handler) {},
	off: function (eventName, handler) {},
	trigger: function (eventName) {}
};

//конструктор (модель)
var Book      = function () {};
Book.byObject = function () {};

var bookService = (new function () {
	var self = this,
	   books = [];
	//добавляем примесь событий сюда
	
	
	self.add = function (data) {
		var newBook = Book.byObject(data);
		books.push(newBook);
		self.trigger('add', newBook);
	};
	//... и т.д. CRUD
	//так же сюда все xhr.
});

//далее view
var BookForm = function ($container) {
	this.onClickSubmit = function (cb) {
		$($container).on('click', '.js-submit', function () {
			cb(formData) //тут можно прокинуть все поля формы
		});
	};
};

//непосредственно инит приложения
$(function () {
	bookService.on('add', function () {
		//Вызвать какое-либо изменения интерфейса
		//Не обязательно BookForm, а любого другого.
	});
	
	var bookForm = new BookForm(/**/);
	bookForm.onClickSubmit(function (formData) {
		bookService.add(formData);
	})
});

Как-то так. Основная идея, что представление и бизнес логика очень слабо связаны. Другой вопрос в том, удобно ли так описывать интерфейсы.

Вместо того, чтобы городить свой собственный eventMixin лучше взять существующий Backbone.


И про такой подход обычно так и говорят — "мы пишем на Backbone", потому что в нем основная логика и крутится.


А когда говорят "мы пишем на jQuery", это означает, что никакой дополнительной библиотеки не используется, а код выглядит примерно как и есть в статье.

Т.е. если бекенд не на JS, нужно писать шаблоны для Vue, которые будут отдаваться «как есть» и Vue будет их уже рендерить, а бекенд будет все отдавать в виде JSON, т.е. что типа API, верно?
Да, шаблоны по сути — html. А на клиенте будут запрашиваться данные с сервера в виде JSON, что бы эти шаблоны и наполнять
А потом приходит сеошник и хочет странного. Например, чтоб роботы текст на странице видели.

А зачем роботу видеть текст в непредназначенном для поисковиков (а возможно — и интернета) приложении?

Правильно ли я понял, что для данной задачи может быть полезен ssr, или это не решает задачи первичного наполнения данными?

Чтобы заполнить список участников повторяющимися полями формы, мы используем тег
Рядом с закрывающим тегом

кажется, что-то пропало…
Видел эту статью на Vue-newsletter, по части перевода хочу отметить переводчику — не стоит гнаться за буквальным переводом фраз.
По сути — перевод весьма неплох. Но, в исходнике напихано достаточно немало устойчивых выражений, которые в русском языке не прозвучат как следует. К примеру, я бы не писал так: «чтобы в кнопке она была правильной», я бы конкретизировал — «чтобы текст в кнопке был правильным». Ну и т.д., а за статью — благодарю, актуальненько.
Если честно, то чудовищный синтаксис у этого Vue. Использование кучи хитроумных кастомных атрибутов в тегах — это современный подход?
В этом отношении jquery на порядок чище и читаемее.
Синтаксис становится читаемее там где пользуются компонентами.Здесь показана как ни парадоксально, именно «код-лапша» на Vue.js. Примитивизм использования допустим только для хелло-ворлда в одну строку. А вот там где нужна запутанная логика — синтаксис уже не решает.Замучаетесь отслеживать кто кого откуда и когда вызывает и что меняет.Попробуйте написать панельку оператора который чз виджет отслеживает посетителей сайта и ведет с ними диалоги и принимает звонки.На ангуляр 1 молиться начнете как нефиг делать.
Тоже на уровне ХеллоВорлд щупали? Да многие ведутся на магию Ангуляра, а потом в реале начинают писать чудо-контроллеры в овер9000 строк.Так что не забудьте пощупать
вглубь до уровня разнесения логики по сервисам, с этого уровня Ангуляр собственно и начинается
Вызов функции syncRemoveButtons() в addAttendee() в примере с jQuery вообще лишний.
Во-первых, спасибо за перевод, наконец-то все прояснилось. А то уже который год читаю про ангуляры-реакты, и везде авторы позиционируют их только как средство для написания SPA, а тут оказывается вполне себе можно заюзать Vue на пацанском сайте с постбэками(=

Перед тем, как полезу глубже, хотелось бы осознать еще пару моментов:

  1. Vue полностью оберегает нас от прямых манипуляций с DOM? Все работает через мониторинг и реагирование на изменение данных? Если так, то есть ли все-таки возможность обращаться к элементам через какой то движок типа Sizzle, или все-таки надо использовать jquery, если не привык к vanillajs? Чтобы, например, проинитить data из какого то элемента.
  2. Насколько гибки Vue-шные атрибуты, отвечающие за работу с DOM? Например, есть ли возможность тому же v-show указать эффект вроде v-show.slide или fade, задать параметры? Или есть ли возможость навесить обработчики не напрямую элементу, а потомкам через предка, как это делает on у jquery?
  3. Если хочется оживить несколько разных областей на странице при помощи Vue, как надо действовать согласно best practices: создавать один Vue на страницу с «под-data-ми» или несколько на каждую область (тогда наверно и с событиями будет меньше путаницы)?
1)А вы ЛЕЗЬТЕ ГЛУБЖЕ) ТАМ и осознаете. А иначе так и будете о каждой теме читать по нескольку лет, а потом очевидные моменты в ней узнавать как откровение.
2)Получать что то по селектору для обслуживания логики приложения обычно считается wrong-way при работе с фреймворками.От так то, благородный дон)

Здесь очень важно понять саму концепцию. Vue и другие фреймворки предлагают подход "создаем DOM из данных" в отличие от jQuery, где "извлекаем данные из DOM". Поэтому возможности обхода по селекторам крайне ограничены. Если нужно получить DOM-ноду — есть ref.


Если планировать использовать Vue, то нужно перестать кодировать данные в data-атрибутах. Здесь показывается, какие есть у Vue альтернативные способы передать данные в компонент.

  1. При использовании vue, данные нужно передавать не через data атрибуты, а через props.
    Вместо


    <div data-initial-value="50"></div>

    Следует писать


    <my-component initial-value="50"></my-component>

  2. Для анимации переключения состоянии во vue используется компонент transition.
    Механизм делегирования событий с родителя на потомков во vue не предусмотрен, в большинстве случаев он и не нужен. Если же у вас нужно обработать события на сотнях или тысячах потомков, то можно повесить обработчик на родителя и в нем вручную проверить, что целью срабатывания был потомок.


  3. На странице может быть только один экземпляр vue, разные области лучше разнести по разным компонентам
Vue.js это крутяк. И Jquery тоже. Пользуюсь и тем и тем и иногда даже вместе.
Only those users with full accounts are able to leave comments. Log in, please.