Pull to refresh

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, или это не решает задачи первичного наполнения данными?

UFO just landed and posted this here
UFO just landed and posted this here
Если честно, то чудовищный синтаксис у этого Vue. Использование кучи хитроумных кастомных атрибутов в тегах — это современный подход?
В этом отношении jquery на порядок чище и читаемее.
UFO just landed and posted this here
Синтаксис становится читаемее там где пользуются компонентами.Здесь показана как ни парадоксально, именно «код-лапша» на Vue.js. Примитивизм использования допустим только для хелло-ворлда в одну строку. А вот там где нужна запутанная логика — синтаксис уже не решает.Замучаетесь отслеживать кто кого откуда и когда вызывает и что меняет.Попробуйте написать панельку оператора который чз виджет отслеживает посетителей сайта и ведет с ними диалоги и принимает звонки.На ангуляр 1 молиться начнете как нефиг делать.
Ангуляр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, разные области лучше разнести по разным компонентам
Спасибо за ответ, хоть рынок все-таки и утащил меня в сторону React(=
Vue.js это крутяк. И Jquery тоже. Пользуюсь и тем и тем и иногда даже вместе.
Sign up to leave a comment.

Articles