Gravio

indexes.reduce((p, c) => (p?.child ?? p)?.[c], main)

var text = "(text) Lorem Ipsum is simply dummy, (text, simply) and (text, simply, qwerty) typesetting industry. Lorem Ipsum has been the[/m]";

let result = text.match(/\([^)]+?(,[^)]+)+\)/g);

console.log(result); // [ "(text, simply)", "(text, simply, qwerty)" ]

Извините, лишнюю скобочку поставил, уже исправил.

db.Query("SELECT * FROM words WHERE id = ANY($1);", pq.Array(list))

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

data: () => ({
  componentNames: [ 'comp1', 'comp2', 'comp3', 'comp4' ],
  ...
}),
computed: {
  componentName() {
    return [ 1, 2 ].includes(this.Q) && this.componentNames[this.B - 1];
  },
},

<component :is="componentName"></component>

UPD. Если дополнительно нужно передавать параметры, то в массиве можно хранить вместо имён компонентов объекты, которые будут содержать имя и набор параметров:

data: () => ({
  components: [
    { name: '...', props: { ... } },
    { name: '...', props: { ... } },
    ...
  ],
  ...
}),

Вычисляемое свойство не изменится (за исключением имени, конечно), а шаблон станет выглядеть так:

<component
  v-if="component"
  :is="component.name"
  v-bind="component.props"
></component>

https://jsfiddle.net/69xv0b47/

Все очень просто. Node.JS крайне медленный, поэтому выбор PHP уже выигрывает. А вообще, в данном контексте будет лучше работать Golang за счет своей скорости.

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

Потому-что, так никто не делает, ну кроме Вас. Для работы auto layout нужно построить цепочку ограничений сверху вниз.

Что бы не спрашивать что у Вас есть, а что нет, сразу напишу полный список./

1) Прописать у layout коллекции:

// ...
layout.estimatedItemSize = UICollectionViewFlowLayout.automaticSize
layout.itemSize = UICollectionViewFlowLayout.automaticSize

2) Соврал, нужно уточнение.

pronunciationLabel - Сколько строк должен занимать? (Только одну?) Увеличивается только в ширину?
wordLabel - Тоже, что и pronunciationLabel? Или увеличивается в высоту?

3) Этот бред больше никогда не нужно делать.

contentView.translatesAutoresizingMaskIntoConstraints = false
   
        NSLayoutConstraint.activate([
            contentView.leftAnchor.constraint(equalTo: leftAnchor),
            contentView.rightAnchor.constraint(equalTo: rightAnchor),
            contentView.topAnchor.constraint(equalTo: topAnchor),
            contentView.bottomAnchor.constraint(equalTo: bottomAnchor)
        ])

Уточнение получены. Продолжим.

Для начала уточним, как нам добиться динамического размера вьюхи в ширину и высоту. Приведу простой и наглядный пример. Создам вьюхи и помещу туда два лейбла. Пишу всё исключительно кодом, т.к. не использую сториборд, но думаю свести проблем не составит. И так:



В принципе мы делаем обычные констрениты, задавая топ и лидинг. Примечателен тут другой момент, а именно трейлинг. Перед его заданием, мы обязательно установили св-ва сопротивление сжатию и сопротивления расстяжения обоим лейблам, давая тем самым системе понять, что хотим видеть лейбл ровно такой ширины, какой он есть на самом деле. После мы делаем констрейнт трейлинг и указываем ему приоритет немного ниже чем 1000(required). Кстати, быть может в сториборде приоритет снижать не придется. Проверьте. (Кажись система делаем это за вас)

С шириной всё готово. Смотрим на костреинты для высоты. Тут вполне обычно, начинаем с топ. После нижний лейбл крепится к боттом первого. И снова небольшая магия. Последний нижний констрейнт снова с пониженным приоритетом. Кстати, быть может в сториборде приоритет снижать не придется. Проверьте. (Кажись система делаем это за вас)

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

Поглядим на примеры:
Первая имеет меньший размер шрифта, но больше символов.

Первая имеет больший размер шрифта, но больше символов.

Первая имеет меньший размер шрифта, но меньше символов.

Первая имеет больший размер шрифта, но меньше символов.


Как видимо размер вьюхи система посчитала вольностью верным. То есть мы динамически научились задавать высоту и ширину ячейки.

Поехали дальше.

Но для ячеек есть ещё одна небольшая проблема. Система лайаута коллекции имеет все нужные констреинты, но она ничего не знает о данных в этих ячеек. А ведь именно они задают ширину ячеейки. Для этого нам нужно в какой-то момент времени немного подсказать системе.

Воспользуемся методом:


Так как все констреинты у нас настроены, нам осталась попросить систему подсчитать нужные размеры и передать новые размеры системе лайаута коллекции. В этот момент кстати, все данные ячейка уже получила. (Текст для лейблов)

И малая ремарка, возможно в метод preferredLayoutAttributesFitting после вызова super. надо будет добавить вызов метода layoutIfNeeded(). А может и не нужно.

Итого:
Добавляем то, что в пункте 1.
Устанавливаем нужные констреинты.
Удаляем ваш код в пункте 3.
Добавляем метод preferredLayoutAttributesFitting

У вас в качестве названия для столбца (show) используется зарезервированное слово для SQL.