Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Не совсем понятно зачем создавать псевдонимы для стандартных функций knockout. Видимо это синтаксический сахар для .NET разработчиков? Не проще ли просто провести внутри команды семинар по использованию библиотеки.
Для своего проекта мы использовали Backbone.JS, обернутый в knockout через knockback. По моему опыту, функции из underscore справляются с поиском по коллекциям быстрее, а синтаксис намного проще + они уже втроены во все коллекции Backbone.
Для своего проекта мы использовали Backbone.JS, обернутый в knockout через knockback. По моему опыту, функции из underscore справляются с поиском по коллекциям быстрее, а синтаксис намного проще + они уже втроены во все коллекции Backbone.
Я бы назвал это — синтаксическим сахаром, чтобы .net разработчики быстрее осваивались в js среде.
Как ни крути, тяжело переходить с C# на js- по себе знаю- этот переход- огромный шок для человека.
Когда разработчик уже освоится, тогда он сам углубится и изучит.
Как ни крути, тяжело переходить с C# на js- по себе знаю- этот переход- огромный шок для человека.
Когда разработчик уже освоится, тогда он сам углубится и изучит.
Переход на сложный проект со множеством библиотек — это, безусловно, шок, согласен. Но больше проблем вызывает нестандартный, не документированный синтаксис, которого не найдешь в стандартных примерах для библиотек. Knowledge gap нужно преодолевать обучением, а не вставляя костыли туда, где они заведомо не принесут пользы.
Синтаксический сахар тут не только в том, что функции «знакомы» разработчикам C#, прелесть линка в том, что вот эти трехстрочные выражения сворачиваются из немалой простыни трудночитаемого текста.
Их быстрее писать, их проще читать и изменять. А оптимизировать можно и «после того как», если вообще будет нужно. Собственно как и на C#.
readability counts©
Их быстрее писать, их проще читать и изменять. А оптимизировать можно и «после того как», если вообще будет нужно. Собственно как и на C#.
readability counts©
Очень интересно насколько undesocre быстрее, быстрее чем что, как измеряли?
Небольшое замечание, в js по умолчанию название методов пишется в camelCase как в java.
Есть такой проект — knockout-projections, от автора Knockout (запись в блоге). В нем есть примерно то, что сделали вы. Не все, конечно. Но у него принцип работы другой — он не создает в памяти новые массивы, а проецирует лениво.
Как же не создается, строчка outputArray = [] там вполне себе в коде фигурирует.
Операция map там такая же, как и здесь. Принцип работы тот же самый — запоминается предыдущее состояние входного массива и выходного.
После сравнения массивов функция-аргумент пересчитывается только для вновь добавленного элемента.
У меня так же, как и там, операции навроде numbers.reverse() или numbers.splice(1, 1) не вызовут функцию аргумент ни разу, перестроив выходной массив ровно также, как и изменился входной. И моя простая, линейная и не создающая лишних сущностей реализация быстрее, как мне кажется.
А операция filter, как мне кажется, бессмысленна, поскольку сложность сравнения массивов O(N*M), а сложность полного перестроения массива — O(N). Вторая операция может стать затратнее первой, если внутри предиката что-то очень тяжелое, чего у нас в проекте пока не встречалось.
Собственно именно по этой причине есть Select, а не только Map.
А то, что сделал я, по большому счету, всего лишь инкапсуляция(+ грануляризация) часто повторяющихся кусков кода, ну и облечение их в приятную С#-разработчику оболочку.
Операция map там такая же, как и здесь. Принцип работы тот же самый — запоминается предыдущее состояние входного массива и выходного.
После сравнения массивов функция-аргумент пересчитывается только для вновь добавленного элемента.
У меня так же, как и там, операции навроде numbers.reverse() или numbers.splice(1, 1) не вызовут функцию аргумент ни разу, перестроив выходной массив ровно также, как и изменился входной. И моя простая, линейная и не создающая лишних сущностей реализация быстрее, как мне кажется.
А операция filter, как мне кажется, бессмысленна, поскольку сложность сравнения массивов O(N*M), а сложность полного перестроения массива — O(N). Вторая операция может стать затратнее первой, если внутри предиката что-то очень тяжелое, чего у нас в проекте пока не встречалось.
Собственно именно по этой причине есть Select, а не только Map.
А то, что сделал я, по большому счету, всего лишь инкапсуляция(+ грануляризация) часто повторяющихся кусков кода, ну и облечение их в приятную С#-разработчику оболочку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linq-подобный синтаксис для knockout