Comments 8
Двойственные впечатления от статьи. С одной стороны текст плохо читаем, трудно определяются акценты. Стилистика бегает от уровня видеоурока по хело ворлд до тонких системных моментов. Что есть не хорошо.
С другой стороны, в этой статьебольшое огромное, по важности, коичество-качество советов. Точный заголовок и тонкий юмор ;) Я попытался в оффисе заболдить те моменты, которые мне показались важными… получилось больше половины статьи.
Благодарен автору, за то, что несколько, вполне простых, советов были для меня как откровение.
С другой стороны, в этой статье
Благодарен автору, за то, что несколько, вполне простых, советов были для меня как откровение.
Может, оно у вас в итоге то и круто получилось, но мешанина из кучи библиотек и фрейворков новичка совсем не радует. Ожидал какого-то более лучшего едиобразного подхода, что ли, а вижу сплошные обёртки и расширения одного другим (это не считая опущеной части). За кучей конструкций самого приложения и не разглядеть.
Добрый вечер.
Это вопрос скорее из разряда целесообразности. Конечно, на небольшом приложении такой подход себя не оправдает. В нашем же случае речь про прилож, в котором минифицированного js-кода 2.5 мегабайта. Плюс «базовый» код переиспользуется в других проектах. Нам такой подход жизнь сильно упростил.
Все согласно закону о необходимом разнообразии Эшби. Сложность побеждает сложность.
Это вопрос скорее из разряда целесообразности. Конечно, на небольшом приложении такой подход себя не оправдает. В нашем же случае речь про прилож, в котором минифицированного 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.
Мысли вслух о разработке javascript-приложений на примере небольшого Line Of Business фреймворка