Комментарии 55
В почившем в бозе rivets.js и в набирающем обороты vue.js используется примерно такой же подход к организации реактивности.
Я не об этом. Про порог вхождения тоже можно поспорить — все-таки наличие многократно вычитанной документации и Q&A снимает множество вопросов.
У vue.js порог вхождения ниже чем в вашем примере имхо. Даже если не читать документацию все интуитивно понятно.
let obj1 = {
this_namespace: 'test',
this_data: ['dataA', 'dataB']
};
obj1._sTpl();
<div data-template="dataA" data-namespace="test"></div>
даже документация не нужна
Что такое data-template? Ссылка на внешний html шаблон? А неймспейс — это… Зачем он? Да и вызов приватного метода _sTpl вообще непонятно что делает. И откуда он у пустого объекта взялся?
Тут документация нужна для каждой строчки, т.к. понятно всё только вам, как автору.
Что происходит дальше описывает статья, и в реализации метода каждая строчка документирована. Еще раз повторюсь — тут задача была в показательности и простоте, без приблуд и претендования на звание фреймворка нуждающегося в документации впринципе, так что «Ссылка на внешний html шаблон?» неуместно, весь метод изначально не для этого предназначен
Да и вызов приватного метода _sTpl вообще непонятно что делает
И вообще откуда этот метод взялся? Там что — расширен прототип Object?
Вы только что предложили прочитать документацию (разновидность её) по примеру, который сказали, что настолько прост, что не требует документации. Верно?
все верно, ок, не «не нуждается в документации», а «минимальный набор работающий из коробки со стремящимся к 0 времени затрат времени на чтение документации»
Хорошо, допустим, а вот такой пример сколько времени на чтение документации требует?
<div id="app">{{ message }}</div>
+
new Vue({
el: '#app',
data: { message: 'izi pizi' }
});
Или ещё лучше, с помощью другого решения (не Vue):
class Some {
message = 'izi pizi';
}
ko.applyBindings(new Some, app);
Неужели больше? Мне кажется что нет, всё очевиднее и, самое главное, прозрачнее на порядки.
Или вы со мной не согласны? Разве возникают хоть какие-то вопросы по этим примерам, аналогичные приведённым мною?
Если хотите сказать о велосипедности — соглашусь.
А я хочу сказать другое — это разбор частного случая на вполне понятном примере
Ну это понятно. Я просто веду к тому, что утверждение, что "порог вхождения в сабжевые фреймы — выше", довольно голословное. Да, там больше плюшек, но понять как работает пользоваться всё же проще, по-моему.
P.S. Во втором случае — нет, при "message = response.message" данные не обновятся, это же просто переменная на чистом JS без какой-либо магии. Для связывания её надо объявить как обсервер (т.е. тупо завернуть внутрь функции ko.observable('izi pizi')), но это не особо важно.
Важно, т.к. мой метод как раз реализует всего одну функцию — связывает представление с данными в автоматическом режиме (если допилить несколькими строчками), максимально быстро (в моем приложении специфическое требование к производительности, на счету каждые 50-100мкс)
Object.prototype._sTpl =
, закрыл.Hasownproperty?
А если серьезно, расширять системные объекты, еще и enumerable свойствами — в лучшем случае дурной тон.
Расширять стандартные прототипы — плохо.
За всем кодом не уследить, что-то где-то сломается.
Так что по сути это Javascript-версия паттерна #define TRUE FALSE
var obj = {
dataA: 1,
dataB: 2
};
var proxy = template(obj, 'test', ['dataA', 'dataB']);
proxy.dataA = 2; // обновляем UI
P.S. По поводу именования переменных с префиксом — попробуйте Typescript, он позволит больше не заниматься сизифовым трудом.
шаблон должен знать, с какими данными он работает
— это можно реализовать пробежавшись по DOM, я писал об этом, но не применил, т.к. это уже другая история.
Про объект-прокси скажу: как логичнее — решается для конкретной задачи.
До typescript я еще не дорос
Шаблон не может не знать о модели данных. В вашем случае атрибутом
data-template="dataA"
вы описываете контракт: для шаблона необходим объект, содержащий поле dataA
. Это нормально и по-другому никак не сделаешь. А вот ссылка из модели на шаблон явно лишняя.не стал добавлять возможность использования в шаблонах каких-то даже примитивных операций (например dataA + dataB)«a + b» — это не логика, а вид представления данных, так же как и «firstname + ' ' + lastname», который можно разложить в `{{firstname}} {{lastname}}`
такая возможность была и там пришлось по-быстрому использовать eval.Не так все просто, вам бы тогда пришлось бы делать паресер выражения и отслеживать все зависимости т.е. +10кб кода, а если прсто eval — то это будет dirtychecking который нужно будет дергать на каждый чих.
распихиваем его в нужные объекты через Object.assign — это будет работать.Это не все, нужно рекурсивно конвертировать объеты ну и с биндингами что-то делать.
Расширение прототипа? В 2017? Это ведь не серьезно!?
Лучше все же использовать Array.from:
Array.from(document.querySelectorAll('.button')).forEach(...)
То, что сейчас проект "ваш", и вы помните о том, что нахимичили с браузерными прототипами, не значит, что другие разработчики это заметят вовремя. Мы же о коммерческой разработке говорим, а не личных домашних веб-страничках
У себя в проекте можете что угодно переопределять, но при публикации код должен быть каноническим.
Какое решение? С расширением прототипа — это плохое решение
Эта возможность была предоставлена не специально, а просто так вышло, потому что язык динамический, и никакой разницы между пользовательскими прототипами и стандартными нет.
Сейчас это работает ради обратной совместимости, в документации явно написано, что такой подход не рекомендуется.
Есть оправдание только для новых фич, которые в будущем поддержатся нативно. Поэтому обычно и пишут так
if(!Array.prototype.forEach) {
Array.prototype.forEach = function () {...}
}
А ваша идея с присвоением метода к NodeList — это отсебятина.
И я бы бежал поскорее от работы с проектом, где такое встречу.
Есть здравые рекомендации по поводу расширения прототипов, и они касаются только расширения недостающими по стандарту свойствами, т.е. годятся только для полифиллов.
UPD: justboris одновременно указали на мдн :)
JS был разработан за 10 дней одним человеком, в нем есть и неудачные моменты, и это нормально.
На данный момент консенсус такой, что расширять прототипы кастомными методами считается плохой практикой. Судьба Prototype.js о чем-то да говорит.
Другое дело полифиллы, потому что они future proof.
Array.from
— стандарт, а полифиллы нужны там, где они нужны.
Простой шаблонизатор на чистом JS со связями