Ember component - явное объявление параметров в компоненте

Мне нравится использовать аддон ember-prop-types для этого случая использования. Это позволяет просматривать доступные свойства, типы каждого свойства, которое принимает компонент, а также устанавливать значения по умолчанию.

Вот небольшой пример того, что он может сделать:

import { Component } from '@ember/component';
import { PropTypes } from 'ember-prop-types';

export default Component.extend({
  // Defines the properties for the component
  propTypes: {
    // Must be a 'string'
    name: PropTypes.string,
    // Must be a 'number' and it's required
    age: PropTypes.number.isRequired,
    // Must be one of the values in the array
    favoriteColor: PropTypes.oneOf(['red', 'blue', 'green'])
  },

  // Defines the default values for the properties if not passed in
  getDefaultProps () {
    return {
      name: 'New User',
      age: 99
    }
  }
});

Я чувствую твою боль по этому поводу. Недавно была проделана работа по поддержке именованных аргументов для компонентов, которые помогли устранить неоднозначность передаваемых параметров из ряда других источников в шаблонах, объединенных в 3.1 . Вы можете увидеть RFC здесь для обоснования. См. Это сообщение в блоге для более подробного объяснения.

Короче говоря, вы можете получить доступ к переданным аргументам как: {{@arg}}, так что вы можете узнать в шаблоне, что это было передано компоненту.

Это помогает, но не завершено. Я обнаружил, что соглашение в понятном компоненте должно включать все аргументы в верхней части файла компонента с комментарием заголовка. Такой пример можно увидеть в ember-power-select (популярный аддон выбора):

  // Options
  searchEnabled: fallbackIfUndefined(true),
  matchTriggerWidth: fallbackIfUndefined(true),
  preventScroll: fallbackIfUndefined(false),
  matcher: fallbackIfUndefined(defaultMatcher),
  loadingMessage: fallbackIfUndefined('Loading options...'),
  noMatchesMessage: fallbackIfUndefined('No results found'),
  searchMessage: fallbackIfUndefined('Type to search'),
  closeOnSelect: fallbackIfUndefined(true),
  defaultHighlighted: fallbackIfUndefined(defaultHighlighted),
  typeAheadMatcher: fallbackIfUndefined(defaultTypeAheadMatcher),
  highlightOnHover: fallbackIfUndefined(true)
  .....

где fallbackIfUndefined - вычисляемый макрос:

import { computed } from '@ember/object';

export default function computedFallbackIfUndefined(fallback) {
  return computed({
    get() {
      return fallback;
    },
    set(_, v) {
      return v === undefined ? fallback : v;
    }
  });
}

В общем, я бы порекомендовал сначала определить, создан ли компонент в домашних условиях или является надстройкой, созданной сообществом. Если последнее, самые популярные из них предоставляют документацию и следуют хорошим соглашениям в своем исходном коде. Вы можете выяснить, находится ли он в доме, посмотрев в каталоге components для компонента (при условии, что это макет не в pods).

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

Но я не уверен, почему вам нужно понимать «все» варианты. Когда я использую компоненты, созданные другими членами команды, я регулярно выполняю поиск их использования в шаблонах и сравниваю этот конкретный пользовательский интерфейс / интерфейс (фактически просматривая браузер) с поведением, которое мне нужно реализовать. Вы должны копать только тогда, когда вам нужно поведение, отличное от существующего в приложении. Это может помочь вам лучше ознакомиться с продуктом, чтобы вы могли лучше узнать, что доступно:)