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
статический ресурс. Давайте проведем рефакторинг нашего статического ресурса, как показано ниже.
Вот что делает код:
- Предоставляет функции
log
,warn
иerror
, для которых изначально установлено значение NOOP (пустая функция). - Затем мы выставляем
logInit()
, который ничего не будет делать, еслиutils.SHOW_LOG === false
(производство), или назначаем соответствующую функцию ведения журнала консоли нашим исходным функциям NOOPlog
,warn
иerror
. - Причина, по которой мы используем
bind
, заключается в том, что мы хотим сохранить контекст, из которого вызывается функция журнала. Это волшебство, позволяющее сохранить номера строк - это необходимо для отладки. (Если вы не знаете, как ключевое словоthis
работает в JavaScript, вам следует потратить некоторое время на его изучение и узнать оbind
иapply
). - Затем мы вызываем
window.utils.logInit();
для инициализации нашего журнала, он вызывается при импорте нашего файла.
Этот шаблон ведения журнала дает несколько действительно хороших преимуществ:
- Мы можем включить / выключить ведение журнала при изменении статического ресурса, который намного проще изменить в производственной среде без изменения кода.
- Нам не нужно выполнять очистку кода перед развертыванием в производственной среде, потому что у нас не будет никаких
console.log()
вызовов - нам просто нужно изменить наш статический ресурс, и мы можем включить его в производственной среде, если нам нужно отладить ошибку, о которой сообщил пользователь. - Исходные номера строк сохраняются, поэтому мы не теряем возможности отладки при такой настройке.
- Мы можем легко поделиться этим с любым компонентом Lightning и иметь единый способ ведения журнала.
Чтобы использовать службу, вызовите любой из методов журнала / предупреждения / ошибки из контроллера или вспомогательного класса utils.log(‘something needs to be logged’, {foo: ‘foo-bar’, bar: ‘baz’})
.
Надеюсь, этот пример вам поможет, дайте мне знать, если у вас есть какие-либо вопросы или комментарии!