Мне не нравятся методы с именем getStuff
. Я предпочитаю, чтобы переменные назывались stuff
. Это кажется естественным, и код имеет другую атмосферу. Однако, когда значение stuff
является динамическим, вы вынуждены использовать функцию и иметь свой код, полный stuff()
.
Если вы используете объекты, вы можете использовать геттеры (obj.stuff
) и иметь лучшее из обоих миров: динамические значения и отсутствие ненужных скобок.
Честно говоря, мне никогда не нравились геттеры в JavaScript. Что мне не понравилось, так это синтаксис Object.defineProperty
, и мне тоже не понравилась альтернатива использования именованных методов get / set (JavaScript - это не Java). Но с момента появления нового синтаксиса получения в ES2015 я время от времени использую геттеры.
Имея дело с модулями CommonJS, экспортирующими динамические значения, мы обычно экспортируем геттерные функции.
Можем ли мы вместо этого экспортировать геттер?
Да мы можем.
Вы можете экспортировать из модуля все, что захотите: какое-нибудь примитивное значение или полноценный объект. И у любого объекта могут быть геттеры.
Вы можете иметь динамическое значение без явного вызова функции. Код имеет другую атмосферу, просто изменив currentDate()
на currentDate
.
Экспорт геттеров и привязки
В общем, когда вы экспортируете объект из модуля, вы должны опасаться возможной деструктуризации в коде, который вызывает require
. Разрушение объекта означает присвоение константе одного из полей объекта. Если это поле является функцией, использующей this
, вы должны обеспечить правильную привязку.
В большинстве случаев значение
this
определяется способом вызова функции (привязка времени выполнения).
В случае метода получения они всегда привязываются к объекту, который их определил. Это означает, что экспортированные геттеры можно безопасно деструктурировать.
В следующем примере вы можете увидеть разницу между обычным методом и получателем. Первая реализация прерывается при деструктуризации currentDate2.
Вторая реализация исправляет это, явно связывая метод с bind
. Получатель работает в любом случае.
Вы должны это сделать?
Возможность что-то делать не означает, что вы должны это делать. Когда я пишу о таких вещах, я всегда говорю одно и то же: стоит ли тебе это делать? Это зависит 🤷🏽♀️.
В основном это вопрос личного вкуса и того, что работает для вашего проекта и команды.
В настоящее время мы используем эту технику только в одном конкретном модуле одного из наших многочисленных проектов. Для нас имело смысл сделать это там. Это упростило наш код и сделало его более читабельным.
Я думаю, что это правильный способ измерить эти вещи: помогает ли он вам? делает ли это проще? это легко понять? Если вы проверяете, проверяете, проверяете, то непременно используйте его.