Комментарии 23
Да, к сожалению, никто еще не реализовал фреймворк, который вбирал бы в себя преимущества observable нокаута, моделей бэкбоуна и роутинга pathjs (ну, или же роутинг контроллера backbone тоже вполне неплох). За ссылочку на обход дата-биндинга в HTML спасибо, хорошая идея. В целом, мне, после копания во всем вышеперечисленном всё же кажется, что нокаут гораздо проще для понимания, хотя и решает всё же немного другие задачи. И да, приятно видеть, что он развивается.
всему свое время. Автору спасибо за статью.
А как вам подход Sproutcore в плане объединения преимуществ нокаута, бэкбона и pathjs?
Ага, тоже советую посмотреть на SC. Он, на мой взгляд, имеет самую лучшую реализацию подходов, описанных в посте.
к сожалению, беглого взгляда на него хватило, чтобы задуматься об избыточности кода. Это, разумеется, субъективно. Если кто-то может показать хороший пример на SC (помимо getting started на офсайте), я буду чрезвычайно благодарен. Пока что меня больше заинтересовало javascript mvc, хоть это и немного разные инструменты.
> data-bind=”visible: currentCustomer() !== null”
настораживают подобные вещи во фреймворке. это очень похоже на onclick="...", на то, от чего отказались годы назад, введя DOM3
настораживают подобные вещи во фреймворке. это очень похоже на onclick="...", на то, от чего отказались годы назад, введя DOM3
Да, я потому и писал о том, что сложные выражения лучше выводить из выражений байндингов в отдельные dependentObservable — а то оглянуться не успеешь, как окажется в коде каша а ля «Привет, 99!»
Для себя определил, что это будет либо имя свойства в модели, либо простое сравнение свойства. Если условие становится сложным — создаю для него зависимое свойство.
При таком подходе можно мысленно считать, что значения data-bind-атрибутов — не код, а правила.
Ну и конечно, не забываем о том, что атрибуты можно расставить потом из JavaScript-кода, тогда ваш HTML останется чистым. Ссылка на реализацию подхода в статье.
Для себя определил, что это будет либо имя свойства в модели, либо простое сравнение свойства. Если условие становится сложным — создаю для него зависимое свойство.
При таком подходе можно мысленно считать, что значения data-bind-атрибутов — не код, а правила.
Ну и конечно, не забываем о том, что атрибуты можно расставить потом из JavaScript-кода, тогда ваш HTML останется чистым. Ссылка на реализацию подхода в статье.
взахлёб читал, спасибо порадовали, весьма полезно. Делитесь опытом не стесняйтесь.
еще один сильный минус knockoutjs по сравнению с backbone — это то, что knockoutjs по сути ведет один человек, при чем комиты совершает довольно редко. У него реально нету времени и например версия 1.3 была аннонсирована очень давно, а воз и ныне там. Я писал свой widget под knockoutjs 1.2 с кучей костылей, надеясь, что с выходом 1.3 я их повыкидываю и что 1.3 появится достаточно скоро — а сейчас сижу как у разбитого корыта — вот начинаю переписывать под backbone
Когда вышел на него, был безмерно счастлив (ну люблю я биндинг). Для серьезных проектов, конечно, рановато (как вобщем-то и backbone), но для фана и несложных проектов — очень даже.
Мы пробовали на серьезном проекте каркас строить на backbone, — к сожалению, еще действительно рано. Изобрев с десяток костылей и достаточно повысив избыточность, после очередного ревью кода было решено переписать всё заново и без backbone
Как я уже сказал, у нас тоже много кода, непосредственно с Нокаутом не связанного, но когда дело касается UI, Нокаут пока обычно работает на нас. Всегда есть два варианта:
Либо DOM под нашим контролем — тогда мы используем байндинги. Это тот случай, на который Knockout и был рассчитан.
Либо DOM создается каким-то третьим компонентом. Тогда задача заключается в привязке его к ViewModel через subscribe. При этом основные сложности возникают всегда с массивами. Если данные одиночные, то дело ограничивается тремя строчками кода, что в общем-то тоже не напряжно.
Либо DOM под нашим контролем — тогда мы используем байндинги. Это тот случай, на который Knockout и был рассчитан.
Либо DOM создается каким-то третьим компонентом. Тогда задача заключается в привязке его к ViewModel через subscribe. При этом основные сложности возникают всегда с массивами. Если данные одиночные, то дело ограничивается тремя строчками кода, что в общем-то тоже не напряжно.
На первой картинке «ResponCe», а нужно «Response». Поправьте плз.
За статью спасибо)
За статью спасибо)
В одном из моих проектов — корпоративной интранет системе (написанной на symfony1.4) пришлось многие модули пришлось реализовывать одностранично. Причём при выборе того или иного элемента, изменении текста требовалось сразу произвести действия на сервере.
Когда собственные велосипеды утомили то попробовал и Knockout и Backbone. Первый не пошёл вовсе, а в
последний влюбился по уши.
Но всё же всё не так однозначно. Knockout очень хорош когда действия пользователя не выходят за рамки страницы, но если нужно обращаться к серверу то, имхо, тут только Backbone.
Хотя… Наверное если бы сразу подумал про Knockout+Amplify, то их совместных возможностей хватило бы для замены Backbone.
Когда собственные велосипеды утомили то попробовал и Knockout и Backbone. Первый не пошёл вовсе, а в
последний влюбился по уши.
Но всё же всё не так однозначно. Knockout очень хорош когда действия пользователя не выходят за рамки страницы, но если нужно обращаться к серверу то, имхо, тут только Backbone.
Хотя… Наверное если бы сразу подумал про Knockout+Amplify, то их совместных возможностей хватило бы для замены Backbone.
Вот еще интересная штука появилась: agilityjs.com/
Выглядит похоже на пересечение нокаута и бэкбона пока что, но я пока еще толком ничего не пытался написать.
Выглядит похоже на пересечение нокаута и бэкбона пока что, но я пока еще толком ничего не пытался написать.
Ага, тоже сегодня на HackerNews увидел, буду наблюдать, но для текущего проекта вряд ли буду переезжать.
Ага. :) Но я, если честно, полистал демки, и что-то меня совсем испугало. В общем, не знаю, пока что для текущего проекта бекбон нравится. Код иногда приходится писать, но всë же просто… нравится. ;)
испугало в смысле то, что хтмл с джаваскриптом вместе. Некрасиво это всë как-то выглядит. :\
Мне кажется, что как и с Нокаутом, нужно искать тонкую грань между «определим правила поведения для элементов» и «OMG!!! JavaScript in my HTML!!1»
С другой стороны, Аджилити позиционируется как библиотека для небольших приложений. Так что многие подходы, которые совершенно недопустимы для средних и больших проектов, тут вполне прокатят.
С другой стороны, Аджилити позиционируется как библиотека для небольших приложений. Так что многие подходы, которые совершенно недопустимы для средних и больших проектов, тут вполне прокатят.
Кстати, на тему нокаутных биндов к джаваскрипту, есть вот такая штука для бекбона — github.com/bruth/synapse
Ухты, похоже на то, что делает jQuery-Link. Недавно на ScriptJunkie была статья о том, как с его помощью реализовать MVVM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Knockout, практический опыт использования