Те люди, которые работают с AngularJS, знают про директиву ngController. В нее передается функция, описывающая поведение блока с директивой. И тут начинается магия! Если наша функция выглядит так:

SomeController = function ($scope) {...};

то она будет вызвана с одним параметром — scope, связанным с контроллером. А если, она выглядит, например, так:

SomeController = function ($http, $location, $scope) {...};

то передаваемых параметров станет внезапно три: два системных сервиса ($http и $location) и тот же самый scope.

Так как же фреймворк определяет, какие параметры нужны для вызова контроллера? Эта магия называется Function.toString(). Метод toString() у функции возвращает ее текст, а дальше дело техники: /^function\s*[^\(]*\(\s*([^\)]*)\)/m. Получили имена параметров, разобрали, подставили. Вот такой нетривиальный подход.

Детали можно посмотреть в исходниках.

Написание доклада подошло к своей финальной стадии. Но чтобы его завершить, мне нужно собрать немножко данных о производительности. А поэтому просьба зайти по следующий двум ссылкам и нажать Run tests. Если вы это сделаете из нескольких различных браузеров, я буду вообще счастлив.

Вот тесты: скорость определения классов и скорость создания объектов.

Заранее спасибо.

В апреле состоится Frontend DEV Conf ’13, на которую меня пригласили прочитать доклад. Я уже активно работаю над ним, чтобы многие смогли вынести для себя чего-нибудь полезное. Самое сложное — это уложить такую большую и сложную тему, как ООП в JavaScript, в связное повествование. В скором времени, когда я закончу активное написание, попрошу кого-нибудь проверить весь текст на адекватность.

Буду рад любым комментариям. И еще больше буду рад всем, кто соберется меня послушать.

Когда в из JavaScript отправляешься AJAX запрос¹, ставишь ему заголовок Content-Type: application/json, но при этом оставляешь само тело запроса пустым, то браузер самостоятельно заменяет Content-Type на тот, который кажется ему более подходящим. Причем для Google Chrome это application/xml, а для Firefox — plain/text. А сервер смотрит на это безобразие и отвечает — 415 Unsupported Media Type, у него-то стоит проверка на заголовок Content-Type.

Как вариант решения отправлять пустой объект {}. Ну или поправить сервер, если есть такая возможность.

Если кто вдруг не знает, Google Closure сильно полагается на JSDoc-комментарии при компиляции и статическом анализе JavaScript-кода. При этом используется не совсем стандартный синтаксис этих комментариев. По крайней мере набор проверяемых инструкций сильно расширен. Кроме того, введена целая система описания типов, которая лучше отражает динамическую структуру JavaScript. Для тех, кто работает с Google Closure с завидным постоянством, всё это не представляет никакой проблемы. Но для тех, кто, как я, возвращается к нему лишь время от времени, периодически приходится заглядывать в руководство. И в помощь таким людям (и не в последнюю очередь себе) я сделал совсем небольшую шпаргалку, чтобы распечатать и повесить на стену перед глазами. Надеюсь, кому-нибудь пригодится.

Скачать pdf (65 Кб, 1 стр.)

Возможно, я ее когда-нибудь расширю, когда придумаю, чего туда добавить, а пока принимаю комментарии, предложения и благодарности.