Подтвердить что ты не робот

Каково понимание в AngularJS?

У меня есть несколько вопросов, жужжащих в голове о выражении понимания:

  • Какова структура данных, которую он определяет?
  • Был ли он адаптирован с другого языка?
  • Где он используется в AngularJS? Этот API существует только для избранных элементов?

Из документов:

ngOptions - comprehension_expression - в одной из следующих форм:

для источников данных массива:

  • метка для значения в массиве
  • выберите в качестве метки для значения в массиве
  • группа меток по группе для значения в массиве
  • выберите группу меток по группе для значения в треке массива trackexpr

для источников данных объекта:

  • метка для (ключ, значение) в объекте
  • выберите в качестве метки для (ключ, значение) в объекте
  • группа меток по группе для (ключ, значение) в объекте
  • выберите группу меток по группе для (ключ, значение) в объекте
4b9b3361

Ответ 1

Выражение понимания - это просто строка, отформатированная особым образом, которая распознается директивой select.

Там нет волшебства, всего несколько форматов, потому что существует множество способов обработки и представления вашей коллекции (структура данных вашей модели, выбор свойств элемента/элемента в качестве модели области видимости, некоторые другие варианты в отношении меток, группировки и т.д.). Когда вы рассматриваете все эти параметры, это не так странно для разрешения сложных выражений.

Скажем, у вас есть такой код:

<select
  ng-model="color"
  ng-options="c.name group by c.shade for c in colors"></select>

Чтобы вырезать выражение понимания и использовать атрибуты, вы должны написать что-то вроде этого:

<select
  ng-model="color"
  ng-data-type="object"
  ng-data="colors"
  ng-select="c"
  ng-label="c.name"
  ng-group-by="c.shade"></select>

Атрибутный подход может стать уродливым после расширения вашего API. Кроме того, с пониманием выражения гораздо проще использовать фильтры.

Ответ 2

Хотя, с одной стороны, верно сказать, что выражение "compthonsion_expression" - это "просто строка", как говорит пакет, с другой стороны, исходный код - это просто строка. Языки программирования - это просто строки.

Оператор SQL SELECT

- что вполне может быть частью вдохновения для синтаксиса и особенностей "comppresion_expression" (но не очевидно, что это так, потому что это не упомянуто в документации) - возможно, если я покопаюсь в некоторых разговорах разработчиков, я мог бы выяснить) -

это просто строка.

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

В то время как выражение comppresion_expression - просто строка, с другой стороны, его сложность почти сводится к тому, что он сам по себе является своего рода подъязыком.

Но то, как оно изображено в документации (https://docs.angularjs.org/api/ng/directive/ngOptions), отражает отношение к тому, что это "просто строка с некоторым форматированием". Это скрыто в документации для ng-options как тип директивы ng-options. В какой-то степени это не отдельное юридическое лицо, это гражданин второго сорта.

То, как перечисляются различные форматы, может вызывать странные ощущения, такие как случайные, без какого-либо паттерна, связывающего различные возможные форматы (хотя есть паттерн, если вы присмотритесь). Без формальной грамматики с регулярной структурой возникает вопрос, действительно ли они охватили все возможные варианты. По сравнению, скажем, с документацией MySQL для оператора SQL SELECT: https://dev.mysql.com/doc/refman/5.7/en/select.html

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

Я подозреваю, что тот, кто задает вопрос, был несколько обеспокоен тем, как небрежно было упомянуто выражение "comppresion_expression" в документах; это может показаться чем-то вроде плавающей, призрачной сущности, только кратко упомянутой, но не имеющей своей собственной страницы и т.д.

Возможно, стоило бы иметь свою собственную страницу, рассматривая ее как отдельную сущность, потому что тогда это вызывает дискуссию относительно дизайна этого "подъязыка". Как это случилось? Каковы причины различных особенностей "подъязыка"? Какие функции и, следовательно, синтаксисы противоречат друг другу? Почему эту функцию можно использовать вместе с этой функцией, а не с другой? Есть ли вдохновение, например, от SQL, в дизайне этого "подъязыка"?

В противном случае это, кажется, изобретение на ровном месте, не связанное с другими DSL в своем роде.

В сообщении в блоге о параметрах ng https://www.undefinednull.com/2014/08/11/a-brief-walk-through-of-the-ng-options-in-angularjs/ г-н Шидхин ссылается на небольшое обсуждение https://groups.google.com/forum/#!topic/angular/4EDe8xIbjLU

Где только этот вопрос обсуждается. "Мэтт Хьюз" также выражает мнение, что "похоже, что для одной директивы много сложностей".

Возможно, это не так уж важно. Я просто хотел показать это там.