Наверняка вы уже слышали о том, что продукт SharePoint Framework вошел в состав платформы Office 365 — появилось сообщение о его доступности для всех желающих. Это важное событие, безусловно, заслуживает нашего внимания. Однако мой опыт однозначно свидетельствует о том, что непосредственно после выпуска какого-либо нового компонента, первичной реализации какой-нибудь услуги или внесения изменений в существующий продукт сотрудники большинства организаций попросту не готовы воспринять нововведение. Часто это объясняется тем, что занятые решением безотлагательных повседневных задач специалисты просто не могут уделять достаточно внимания отслеживанию разного рода перспективных новинок. В итоге мы нередко занимаемся поисками в Интернете и перебираем материалы, отобранные поисковиками Google или Bing в надежде, что кто-то другой уже столкнулся с такой же проблемой и поделился своим решением в блоге. Здесь, кстати, надо отметить, что специалисты Microsoft сделали доброе дело: задокументировали большинство проблем, с которыми потребители могут столкнуться или о которых они должны знать. Впрочем, проведенная в Microsoft работа охватывает не весь круг интересующих нас вопросов.

Как раз один из таких вопросов всегда встает перед нами, когда мы разрабатываем решения с помощью SharePoint Framework. Речь идет о структуре создаваемого нами кода, в первую очередь о существующих сценариях JavaScript или программных решениях на стороне клиента, на которые нам приходится переходить. Когда мы пишем код на языке JavaScript, мы должны иметь в виду, что существуют три представления о том, как это делается. Первая схема — асинхронное определение модуля Asynchronous Module Definition (AMD). Этот метод прост и логичен. Он позволяет нам определять функции и представлять методы, которые могут использоваться на всем пространстве нашего кода. Код AMD может выглядеть так, как показано на экране 1.

Пример кода Asynchronous Module Definition
Экран 1. Пример кода Asynchronous Module Definition

Если бы мы захотели сгенерировать тот же фрагмент кода с использованием второй схемы, которая именуется CommonJS, нам пришлось бы несколько изменить его. Данный подход обычно применяется в тех случаях, когда программист написал кодовый фрагмент для Node.js (экран 2).

Пример кода для Node.js
Экран 2. Пример кода для Node.js

Наконец, мы можем написать код в формате Universal Module Definition (UMD). Этот формат становится все более популярным, и если мы присмотримся к некоторым фрагментам базового кода SharePoint Framework, то убедимся, что разработчики кое в чем следуют его схеме (экран 3).

Код в формате Universal Module Definition
Экран 3. Код в формате Universal Module Definition

Каждый из форматов работает, каждый выполняет одну и ту же задачу, но при этом каждый имеет свои достоинства. Если бы мне нужно было написать относящуюся к среде веб-часть кода SharePoint Framework, я лично выбрал бы синтаксис, представляющий нечто среднее между схемами...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF