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

В виде шара (где better-component - это имя ключевого слова статического компонента).

{{better-component <strong i="8">@arg</strong> staticString=true}}

Это позволит аддонам указывать, что конкретный «динамический вызов» работает, только если вызывающий предоставляет статическую строку.

Мы должны делать это только в том случае, если на практике множество случаев динамических компонентов вызвано прямым «строковым аргументом, переданным аддону».

Идентифицируйтесь, если это по теме этой проблемы, но я периодически пытался выяснить полную статичность на emberclear и вёл бумажный след проблем и их решений.

https://github.com/NullVoxPopuli/emberclear/pull/784

Итак, если люди сталкиваются с проблемами, может быть, документация Эйба может помочь? Идк

Кроме того, я очень рад вышивать, и у меня уже есть большие планы, когда достигается полная статичность.
https://github.com/emberjs/rfcs/issues/611

Наше приложение представляет собой систему доставки динамического контента. Создатели контента собирают контент из «элементов деятельности», каждый из которых имеет соответствующий компонент Ember, имя которого определяется в модели данных Ember. Суть этой системы примерно так выглядит:

// example model definition
export default class TextElement extends Model {
  _componentName = 'text-element';
}

  {{#each (sort-by "position" @activityElements) as |activityElement|}}
    {{component (get activityElement "_componentName")}}

Мое прочтение вышеизложенного предполагает, что это сценарий (component dynamicString) . Это точно?

Мое прочтение вышеизложенного предполагает, что это сценарий (компонент dynamicString). Это точно?

Что такое @activityElements и где оно определяется?

Это будет массив экземпляров модели данных Ember, переданный в компонент контроллера .

Мы также много вложили в динамические компоненты, к сведению. Я спрашивал об этом здесь в прошлом году: https://discuss.emberjs.com/t/the-perils-of-dynamic-component-invocation/16784.

И мы тоже. Мы буквально не знаем заранее, какие компоненты будут использоваться в приложении. Они хранятся в базе данных (что, конечно, делает их изменяемыми), компилируются на бэкэнде и отправляются по запросу во фронтенд. Невозможность использовать динамический помощник component для нас - это то же самое, что неспособность использовать для каждого в массиве. Я очень надеюсь, что для подобных случаев есть какой-то путь вперед. Я определенно не буду беспокоиться о разделении кода / встряхивании дерева, если мое приложение не работает, потому что у меня нет нужного динамизма.

Можно ли использовать карту всех допустимых компонентов для этого сценария?

Например:

{{#let (hash
   Foo=(import 'path/to/foo')
   Etc=...
) as |validComponents|
}}
  {{component (get validComponents @someDynamicValue)}}
{{/let}}

?

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

Можно ли использовать карту всех допустимых компонентов для этого сценария?

Это определенно покрывает наш вариант использования.

@NullVoxPopuli @jherdman Замечательно !

В общем, можно подумать о том, что людям нужно делать вместо (component dynamicString) это то, что им нужно куда-то пойти import или (component "staticString") .

Варианты включают:

• вызывающий компонент сделает (component "staticString")
• код с динамизмом перечислит возможности, поместит их на карту и воспользуется (get componentMap dynamicString) чтобы извлечь их

Теперь вы можете подумать: как может (get components dynamicString) быть лучше, чем (component dynamicString) ? Ответ состоит в том, что componentMap нужно было где-то построить, и правила применяются рекурсивно.

Предположим, вы пишете компонент, который позволяет писать <InputField @type="text" /> или <InputField @type="checkbox" /> (например, <input> в HTML).

Ваш шаблон для input-field будет выглядеть примерно так:

{{#let (hash text=(component "inputs/text-field") checkbox=(component "inputs/checkbox")) as |components|}}
  {{component (get components @type)}}
{{/let}}

Когда вы пишете код таким образом, Embroider может видеть, что в комплект нужно включить только два компонента. Если бы вы написали это так:

{{component (concat "inputs/" <strong i="33">@type</strong> "-field")}}

(да, такие вещи на удивление распространены)

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

export default class extends Component {
  get innerComponent() {
    return `inputs/${this.args.type}-field`;
  }
}

с этим шаблоном:

{{component this.innerComponent}}

Это небольшая настройка, но она позволяет Embroider определять, какие компоненты фактически используются.

Я также хочу более тщательно описать связи с двумя другими функциями в полете.

1. Импорт шаблонов
2. Использование классов компонентов в качестве вызываемых

Если мы перепишем предыдущий пример, используя эти две функции, он будет выглядеть так:

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

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

Использование классов компонентов в качестве вызываемых

Начиная с RFC # 481 , класс компонента был полностью автономным модулем, который имеет всю информацию, необходимую виртуальной машине Glimmer для вызова его в качестве компонента.

Примечание. Это верно не только для классов, которые наследуются от @ember/component или @glimmer/component . Начиная с RFC 481, определение Ember для «компонента» - это «объект, связанный с шаблоном и менеджером компонентов», который включает в себя пользовательские компоненты, такие как подключенные компоненты .

Начиная с RFC # 432 (контекстные помощники и модификаторы) и RFC # 496 (строгий режим управления), дизайн будущего синтаксиса шаблона Ember следующий: выражения, содержащие помощники, компоненты или модификаторы, могут быть вызваны как помощники, компоненты или модификаторы.

Смысл текущего набора утвержденных RFC заключается в том, что <SomeComponentClass /> (или <this.componentClass> где this.componentClass преобразуется в класс компонента) "просто работает". Это также план записи работ по внедрению.

Тем не менее, для ясности мы должны создать новый RFC, который явно определяет это поведение.

Указать список допустимых компонентов в HBS где-нибудь возможно, но есть пара предостережений, на которые стоит обратить внимание:

1. В настоящее время мы используем JS-решение, указанное @wycats . Сделать то же самое с провайдером HBS можно, но, как мы все знаем, логика в HBS немного сложнее. Кроме того, намного сложнее выполнить модульное тестирование того, что компонент-поставщик дает правильный компонент, чем служебная функция, возвращающая правильные строки.

2. Этого не существует в JS (в любом случае с общедоступным API) afaik, но использование структуры каталогов в наших интересах было бы здесь очень хорошо. Например:

   {{#let (lookup-directory "components/inputs/") as |components|}}
   {{/let}}
   

   Со временем может оказаться, что такие вещи будет легче поддерживать, если вы знаете полиморфные типы, сгруппированные по структуре каталогов.

В любом случае, мне кажется, что динамическим компонентам нужно обсудить отдельную проблему, а не решать эту 🙈 😄

В любом случае, мне кажется, что динамическим компонентам нужно обсудить отдельную проблему, а не решать эту 🙈 😄

Я согласен, и вскоре открою его в репозитории RFC и опубликую здесь ссылку.

@mehulkar @wycats @jherdman а как насчет того, чтобы разрешить пользователям просто импортировать свой список динамически вызываемых компонентов? Кажется, гораздо легче следовать, чем помощник, который включает дополнительный уровень косвенности.

import Component1 from './dynamic/component-1';
import Component2 from './dynamic/component-2';
import Component3 from './dynamic/component-3';

export default class extends Component {
  get innerComponent() {
    switch(this.args.type) {
      case 'one':
        return Component1;
      case 'two':
        return Component2;
      case 'three':
        return Component3;
      default:
        // handle invalid type
    }
  }
}

Тогда шаблон может просто делать: {{#let (component this.innerComponent) as |DynamicComponent|}} или что-то подобное.

Я бы предпочел что-то подобное, чтобы было проще искать / читать / анализировать и легко определять, где эти компоненты используются. Мысли?

@Samsinite да, я думаю, это идея. Помощник в HBS в основном будет синтаксическим сахаром и полезен для компонентов, содержащих только шаблоны.

@Samsinite, это в основном то, что я предложил в качестве краткосрочного исправления (до импорта шаблона).

Это потребует от нас разрешения вызова классов компонентов, о чем я говорил в этом комментарии .

Давай сделаем это!

Ах, это имеет смысл только для компонентов шаблона, извините за недопонимание :). Мне также нравится синтаксис только для компонентов шаблона:

---
import TextField from "./text-field";
import Checkbox from "./checkbox";
---
{{#let (hash text=TextField checkbox=Checkbox) as |components|}}
  {{component (get components @type)}}
{{/let}}

Кроме того, на самом деле, я бы, вероятно, использовал его только для шаблонов и компонентов с поддержкой js, в зависимости от того, что другим в команде будет легче читать.