Pull to refresh

Comments 8

Двойственные впечатления от статьи. С одной стороны текст плохо читаем, трудно определяются акценты. Стилистика бегает от уровня видеоурока по хело ворлд до тонких системных моментов. Что есть не хорошо.

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

Благодарен автору, за то, что несколько, вполне простых, советов были для меня как откровение.
Спасибо за отзыв. Писательский навык буду усиливать. Ощущение, что он слабоват у самого есть :)
Скачки стиля также вызваны тем, что изначально написанный материал ужимали, поскольку получилось больше 70 страниц и такой объем вообще мало кто стал бы читать.
Может, оно у вас в итоге то и круто получилось, но мешанина из кучи библиотек и фрейворков новичка совсем не радует. Ожидал какого-то более лучшего едиобразного подхода, что ли, а вижу сплошные обёртки и расширения одного другим (это не считая опущеной части). За кучей конструкций самого приложения и не разглядеть.
Добрый вечер.
Это вопрос скорее из разряда целесообразности. Конечно, на небольшом приложении такой подход себя не оправдает. В нашем же случае речь про прилож, в котором минифицированного js-кода 2.5 мегабайта. Плюс «базовый» код переиспользуется в других проектах. Нам такой подход жизнь сильно упростил.
Все согласно закону о необходимом разнообразии Эшби. Сложность побеждает сложность.
Впечатление от кода: его трудно читать и он многословен.
Примеры:
listViewModelDef.superclass.constructor.call(this, title);

ko.bindingHandlers.bufferedListPager.init(element, valueAccessor, allBindingsAccessor, viewModel);

testListDef.superclass.constructor.call(this, 'Тестовый список');



Убежден, что причина именно такого кода — педантичность автора.
Не навязываю, но как совет: будет лучше, если всю эту «ненужную» мишуру спрятать как-то в недра. Ведь чем меньше видишь кода, тем проще его понимать. А спрятать всегда можно — было бы желание :)

Спасибо за материал, особенно за after в биндинге для форматирования и пример использования extenderов. Я тоже пишу большие приложения на нокауте, однако совсем не использую примеси и наследование. Пугают большие единые монолитные объекты намешанные из кучи всего. Обхожусь небольшими моделями с обвязкой, которые называю виджетами, и которые общаются друг с другом через eventEmitter. Ошибки в одном виджете меньше влияют на всю систему, чем ошибки в общей примеси. Несколько человек могут писать свои виджеты одновременно в одной системе. Если интересно — github.com/Kasheftin/ko-widget — реп с движком, на котором работают мои последние проекты.
Спасибо за статью. Полезно.

Но всё-таки правильней звучит на русском «байндинг».
А рабочий пример всего описаного на гитхабе есть?
Sign up to leave a comment.