Роман Якимчук

У вас HTMLCollection, а не массив, поэтому forEach нет.

Два варианта:
1. [...document.getElementsByClassName("allow")] для перевода в массив, и далее делаете forEach
2. Если не нужна Live-коллекция элементов, используйте querySelectorAll чтобы найти элементы

Вариант №2 обычно предпочтительнее.

И, не меняйте всё свойство style, а лишь нужный стиль:
e.style.background = 'red';

Поэтому если записать всё максимально коротко, то:

[...document.querySelectorAll('.allow')].forEach(element => {
  element.style.background = 'red';
});

Есть несколько важных моментов при тестировании:
1. Возможности библиотеки
2. Скорость тестирования
3. Популярность инструмента

Так вот, Jest, по моему опыту использования, отвечает всем параметрам. Раньше был Jasmine (это база Jest, насколько я знаю), и там сильно не хватало параллельного запуска тестов, а в Jest это решили, и сейчас он очень быстро прогоняет тесты.

Mocha не так популярна, да и из коробки есть не всё, надо или Chai ставить, потом Sinon, и так собирать нужное решение. Параллельного запуска тестов тоже из коробки нет. Поэтому, можно использовать, но придется самому собирать нужное решение под тестирование.

QUnit не использовал, но всегда думал что это устаревшая штуковина

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

Поэтому рекомендую Jest :+1:

Если код не меняется, а выдача разная, дебажьте переменную $tamines

Похоже, что есть опечатка:

open() {
        this.close = false
    }

    close() {
        this.close = true
    }

Должно быть closed, судя по всему

Здесь проблема со структурой. Если атрибут относится к категории, он должен быть внутри её модели, а не отделен от неё. Поэтому и не получается обратиться сразу к двум свойствам из одного цикла, плюс возникает сложность по определению соответствий атрибутов и названий категорий.

Текущую структуру можно вывести так:

const testdata = [
            {
                category: ['Категория-1_1', 'Категория-2_1','Категория-3_1',],
                attr: [ 'attr1', 'attr2', 'attr3'],
            },
            {
                category: ['Категория-1_2', 'Категория-2_2','Категория-3_2',],
                attr: [ 'attr1', 'attr2', 'attr3'],
            }
        ];

const templates = testdata.reduce((acc, item) => {
  return acc.concat(...item.category.map((category, index) => {
    const attr = item.attr[index] || '';
    return `<button class='category-btn' data-categoty='${attr}'>${category}</button>`;
  }));
}, []);

На выходе будет массив:

0: "<button class='category-btn' data-categoty='attr1'>Категория-1_1</button>"
1: "<button class='category-btn' data-categoty='attr2'>Категория-2_1</button>"
2: "<button class='category-btn' data-categoty='attr3'>Категория-3_1</button>"
3: "<button class='category-btn' data-categoty='attr1'>Категория-1_2</button>"
4: "<button class='category-btn' data-categoty='attr2'>Категория-2_2</button>"
5: "<button class='category-btn' data-categoty='attr3'>Категория-3_2</button>"

Рекомендую переписать на CSS @keyframes и описать всю анимацию от её старта и до конца. Тогда, вероятно, JS не понадобится от слова совсем (разве что классы повесить при наведении мышки), и работать будет стабильно (всё будет на стороне браузера).

https://developer.mozilla.org/en-US/docs/Web/CSS/C...

И надо бы классы сделать, но не могу найти сходу нормального примера. Идея такая же, как здесь https://docs.angularjs.org/guide/animations.

Трудно понять как работает решение, но, похоже что спроектировано неверно.

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

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

Если простое решение, то можно сделать через замыкание, т.е. делается IIFE (функция, которую объявили и сразу же вызвали), внутри неё создается переменная, и возвращается вам слушатель, и тогда из слушателя можно будет перезаписывать эту внешнюю переменную.

element.addEventListener('click', function () {
  var sharedVariable;

  return function () {
    sharedVariable = 1; // Здесь переменная всегда доступна для чтения и записи
  }
}());

В любом случае рекомендую менять архитектуру.

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

Дело не в Angular, а в том что такое интерфейс. Я расскажу со стороны моей практики.

Интерфейс это контракт взаимодействия между техническими сущностями (классы, объекты, функции, и так далее). Если мы создаем 10 объектов, которые соблюдают (реализуют) интерфейс, значит их можно подменять друг другом (только не нужно нарушать LSP, это принцип SOLID).

Так вот, отсюда есть мощные бонусы:

Первое, если создавать интерфейсы, то сущности начинают зависеть не друг от друга, а от интерфейса. Это значит что вместо зависимости одного класса от другого конкретного класса, можно использовать зависимость от интерфейса и любой класс реализующий интерфейс. Таким образом, если понадобится, можно спокойно заменить один класс на другой, если они реализуют один и тот же интерфейс. Это называется принцип инверсии зависимостей (один из принципов SOLID).

Выходит что сущности не завязываются друг на друга, и их можно разрабатывать независимо друг от друга, а в разработке чем меньше связей между классами/объектами, тем лучше. Если потом понадобится изменить код, поменять класс, будет значительно меньше проблем. Меньше, потому что если есть цепочка зависимостей, то нельзя изменить что-то одно, потому что другое сломается, и придется менять всю цепочку. Убирая прямые зависимости изменение кода становится проще.

Второе, это стабильность, лично для меня. Я работаю на TypeScript, и там можно описать интерфейс, сигнатуру функции, и ожидать на входе любые данные, которые его реализуют, и вообще пофигу откуда они, но пока они реализуют интерфейс, всё будет работать стабильно.

Третье, это понимание с чем ты работаешь. Когда есть интерфейс, ты всегда понимаешь что можно использовать у объекта, что там есть, и какого это типа. Просто очень удобно.

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

Ты сначала думаешь как оно будет работать, какие есть данные, потом описываешь это через интерфейсы, и прочее, а потом реализуешь. Поэтому можно считать что интерфейс это один из ключевых строительных блоков архитектуры приложения. Без него сущности будут пытаться дергать нужные им данные от объектов на входе, без понимания можно ли их вообще оттуда дергать, что там вообще реально есть, и в итоге получится хаос.

Поэтому Ангуляр собственно не причем, это просто фреймворк, а принципы проектирования там те же самые, как и в любом другом приложении.