tl;dr

Используйте статические ресурсы для совместного использования служебного javascript во всех ваших компонентах Lightning. Посмотрите примеры кода, чтобы узнать, как создать служебную программу для ведения журнала, чтобы избежать использования console.log в коде и легко отключить журналы в производственной среде без изменения кода компонентов.

Резюме

Я потратил некоторое время на разработку платформы Lightning и хотел бы поделиться своим опытом, а также некоторыми шаблонами, которые могут помочь вам в путешествии по фреймворку Aura. Как и в случае с другими частями «платформы», Salesforce предоставила множество документации для разработки с помощью Lightning, но документация разбросана по многим страницам с разным уровнем детализации и тщательности. Поскольку дорога была для меня немного ухабистой, я хотел бы поделиться своими впечатлениями.

Я - полнофункциональный разработчик, обычно работающий с Angular или React, и меня иногда раздражают ограничения, связанные с платформой Salesforce.com. Первое раздражение, с которым я столкнулся, заключалось в том, что helper функции были привязаны к компоненту. В целом это нормально, но мне стало интересно, где я могу разместить базовые служебные методы, которые я хотел бы использовать в любом месте своего приложения. Хорошая новость в том, что Salesforce дает инструкции, как это сделать.

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

Создание регистратора

Сначала создайте новый статический ресурс с очевидным именем, например utils или lightning_utils.

В этом примере давайте добавим новое свойство utils к поддельному объекту window (он использует LockerService из Salesforce, а не фактический объект window).

После сохранения статического ресурса этот код будет доступен в любом из наших компонентов, которые импортируют статический ресурс с использованием <ltng:require />.

Примечание. Это нужно сделать только один раз в самом верхнем компоненте дерева компонентов.

Если вам нужно использовать несколько ресурсов, обязательно используйте встроенный метод join(), чтобы загрузить их все.

<ltng:require scripts=”{!join(‘,’, $Resource.utils, $Resource.lodash, $Resource.momentjs)}” afterScriptsLoaded=”{!c.doInit}” />

Теперь вы можете вызывать utils.foo() из ваших компонентов или вспомогательных функций компонентов - УРА!

А теперь давайте посмотрим на что-нибудь более полезное, например, на создание универсального регистратора для вывода этих console.log() вызовов из вашего кода в наш utils статический ресурс. Давайте проведем рефакторинг нашего статического ресурса, как показано ниже.

Вот что делает код:

  1. Предоставляет функции log, warn и error, для которых изначально установлено значение NOOP (пустая функция).
  2. Затем мы выставляем logInit(), который ничего не будет делать, если utils.SHOW_LOG === false (производство), или назначаем соответствующую функцию ведения журнала консоли нашим исходным функциям NOOP log, warn и error.
  3. Причина, по которой мы используем bind, заключается в том, что мы хотим сохранить контекст, из которого вызывается функция журнала. Это волшебство, позволяющее сохранить номера строк - это необходимо для отладки. (Если вы не знаете, как ключевое слово this работает в JavaScript, вам следует потратить некоторое время на его изучение и узнать о bind и apply).
  4. Затем мы вызываем window.utils.logInit(); для инициализации нашего журнала, он вызывается при импорте нашего файла.

Этот шаблон ведения журнала дает несколько действительно хороших преимуществ:

  1. Мы можем включить / выключить ведение журнала при изменении статического ресурса, который намного проще изменить в производственной среде без изменения кода.
  2. Нам не нужно выполнять очистку кода перед развертыванием в производственной среде, потому что у нас не будет никаких console.log() вызовов - нам просто нужно изменить наш статический ресурс, и мы можем включить его в производственной среде, если нам нужно отладить ошибку, о которой сообщил пользователь.
  3. Исходные номера строк сохраняются, поэтому мы не теряем возможности отладки при такой настройке.
  4. Мы можем легко поделиться этим с любым компонентом Lightning и иметь единый способ ведения журнала.

Чтобы использовать службу, вызовите любой из методов журнала / предупреждения / ошибки из контроллера или вспомогательного класса utils.log(‘something needs to be logged’, {foo: ‘foo-bar’, bar: ‘baz’}).

Надеюсь, этот пример вам поможет, дайте мне знать, если у вас есть какие-либо вопросы или комментарии!