При написании больших JavaScript-приложений одна из самых простых вещей, которую можно сделать, это разделить код на несколько файлов. Это улучшает поддерживаемость кода, но увеличивает шансы потерять или ошибиться со вставкой тега script в главный HTML-документ. Отслеживание зависимостей затрудняется с ростом числа файлов проекта. Эта проблема присутствует в больших AngularJS приложениях до сих пор. У нас есть целый ряд инструментов, которые заботятся о загрузке зависимостей в приложении.

В этой статье мы рассмотрим, использование RequireJS с AngularJS для упрощения загрузки зависимостей. Мы также рассмотрим, как использовать Grunt для генерации файлов, содержащих модули RequireJS.
Читать дальше →

По названию публикации некоторые могли подумать: «Что опять?! Еще один велосипед?» Спешу обрадовать – нет. Well.js (Github) – это обертка для существующих AMD-решений (по-умолчанию для Require.js), основная идея которой сделать работу с модулями и их зависимостями, как показалось автору, более привлекательной.

Например, возьмем модуль Require.js:

define(['views/common/basic-page', 'views/partials/sidebar', 'utils/helper', 'models/user'  ], 
	function (BasicView,SidebarView, Helper, UserModel) {  
	//тело модуля  
});  

И легким движением руки заменим на это:

wellDefine('Views:Pages:Overview', function(app, modules) {  
	this.use('Views:Common:BasicPage')  
		.use('Views:Partials:Sidebar')  
		.use('Utils:Helper', {as: 'MyHelper', autoInit: false})  
		.use('Models:User', {as: 'UserModel'})  
		.exports(function(options){  
			/* Теперь к зависимостям можно получить доступ через:  
			this.BasicPage  
			this.Sidebar  
			this.MyHelper  
			this.UserModel  
			*/  
		});  
});  

Кому интересно, для чего все это надо, прошу под кат.
Читать дальше →

Идея данной статьи родилась после тяжелого рабочего дня при 30 градусах в офисе и тяжких раздумий и холиваров на тему: «А как должно строиться современное веб-приложение?»

И тут мне пришла в голову мысль изложить свой процесс работы над задачей на Хабре. И сам разберусь до мелочей, и внесу вклад в знания сообщества.

О чем пойдет речь в данной статье? Я напишу (не)большое приложение на TypeScript, которое будет реализовывать модульную архитектуру, асинхронную загрузку модулей, абстрактную событийную модель и обновление состояния модулей по наступлению определенных событий. Эта статья будет выступать как бы дневником и журналом моих действий и размышлений. Моя личная цель — создать некоторый рабочий прототип, опыт создания которого я потом мог бы использовать в рамках реального проекта. Код будет писаться максимально аккуратно и близко к требованиям реальной разработки. Пояснения будут даваться так, будто это потом будут читать работающий под моим руководством джуниоры, которые вообще до этого никогда такие системы не писали.

Статья будет разбита на куски, которые я буду выкладывать на суд общественности по мере готовности. Первая часть посвящена общей постановке задачи, модулям и их асинхронной загрузке.

Итак, дав себе и сообществу эти обещания, включив AC/DC и собравшись с мыслями я приступаю. Читать дальше →

У меня сложилось впечатление, что в обществе все же есть предубеждение против использования глобальных переменных в служебных целях. В связи с этим, хочу дать некоторые разъяснения с примерами, которые снимут всякие сомнения и будут полезны всем, кто жаждет модульности и гибкости в JavaScript разработке. Я не могу проследить источники всех идей, приведенных ниже, но я не претендую на их авторство, а лишь на творческое обобщение. Так же я отказываюсь от претензий на один универсальных паттерн определения модулей для всех случаев жизни, надеюсь, всем ясно, что такого не может быть никогда. Все это существенно отличается от подходов RequireJS, CommonJS и того, как модули оформляются в node.js через module.exports, однако, каждый из этих паттернов имеет свое место, если подходить к задаче без фанатизма и предубеждений.
Читать дальше →

Я тут пишу одну эпическую мегахрень, которую хочу пропиарить на хабре. Эта штука типа распределенной социальной сети. Там есть ядра с api, которые общаются по некоторому стандарту и фронтенд. Особенностью сети является то, фронтенд живет «отдельно» от ядра, то есть сеть не имеет своего домена — берем html, ставим ссылку на любое ядро и получаем сеть, которая живет поверх сайта. Внешне это похоже на социальные плагины фейсбука — комментарии и лайки оттуда можно поставить на любую свою страницу — только вместо тегов fb-like используются мощные биндинги knockout.js + пользователь не ограничивается огрызками из комментариев и лайков — на сайт можно импортировать практически любой блок из сети и сделать почти любое действие. Фронтенд написан на тех же технологиях, которые юзер может использовать и дописывать на своей странице.

В результате образовалась техника, которая может быть интересна фронтендщику. Эту технику хочу разобрать в этой статье.

Расскажу про систему, которая встраивается на html-страницу через биндинги нокаута. Код живет в подключаемых виджетах, которые состоят из html-шаблонов с knockout-обвязкой. Виджеты могут быть вложены друг в друга. Все это использует require.js и живет в amd форме. Зависимости от внешней страницы сведены к минимуму, все библиотеки (jquery, knockout и плагины) используются только свои в локальном пространстве с namespace-ами. Для сборки кода используется r.js. Еще как крутые перцы напишем на базе бутстраповского диалога полноценный оконный менеджер — с нокаутом это как два пальца об асфальт…
Читать дальше →