Иван В

addEventListener('click', ()=>styleStaps(i))

Вы ведь сами понимаете, что это ваш косяк, а не заказчика? А чего ему за него платить?

Мне прям вспомнилась ситуация, когда я пришёл к стоматологу вылечить кариес (пусть будет 2 000 рублей), мне рассверлили весь зуб и заявляют "батюшки, да тут же пульпит!" (12 000 рублей).
Помогите Маше найти фразу для стоматолога, которая позволила бы сохранить хорошие отношения.

И вот вы сейчас, по прошествии 2 месяцев, оставите заказчика один на один с незавершённым проектом, в котором никто не разберётся (то есть по сути ни с чем) - то вы поступаете как чудак. Я же вижу по тексту, что понимаете.
А сюда вы за индульгенцией пришли? :)

Хотите "сохранить отношения" - доделывайте как есть, в будущем будете мудрее.

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

Два совета на будущее:
1) Перезакладывать стоимость и время разработки;
2) Если понимаешь, что всё идёт не по плану/пропал интерес / слишком сложно / некомфортно / whatever - сказать об этом сразу и отказаться от проекта, так всегда получается честнее

Опыт всегда стоит дорого, а 53 000 рублей - ну не самая большая цена его получения :)

Вопрос задан не очень верно. React из него, на текущем уровне следует выкинуть.
Далее ознакомится с пирамидой тестирования. Это уже закроет часть вопросов о том, что к какому типу тестов относится. Только после этого следует переходить к специфики реакта.

Но если ответить на вопрос, то функции с помощью jest или аналогов.
Сами компоненты React-Testing-Library + Jest
Взаимодействие компонентов либо всё теми же React-Testing-Library + Jest, либо чем-то из интеграционных: TestCafe или Cypress или аналогом
Ну и полные сценарии от открытия страницы до совершения последнего в цепочке целевого действия TestCafe или Cypress или аналогом

Рекомендуют покрытие Unit тестов не менее 90%, причем после обработки через stryker mutator
Интеграционные и e2e по критическим сценариям

Как-то так

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

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

В качестве примера можно привести Reducer.
Если есть опыт работы с Redux, то я думаю, поймешь о чем речь.
Если нет, то:
Представь, что в приложении есть некий общий объект, который хранит в себе некие данные этого приложения. Например произошёл запрос на бэкенд, получен ответ, и данные сохранились в этом объекте. К этому объекту есть доступ у всех компонентов приложения. Т.е. отпадает потребность туда сюда из компонента в компонент передавать эти данные в виде props.
Данные в этом объекте может менять определенная функция. И этой функцией является редьюсер. И этот редьюсер и должен быть конечным автоматом.
Т.е. в редьюсер передаются данные, он эти данные принимает, распознает не при помощи if else, а при помощи switch case, так как это удобнее, и меняет данные в объекте. И, в следующий раз при передаче этому редьюсеру этих же данных, он поменяет данные в объекте абсолютно точно также.

const reducer = (state, action) => {
 switch(action.type) {
  case "new value":
  return{...state, value: action.payload}
}
}

Методы класса, объявленные таким образом, лежат в прототипе (каждый такой метод будет общий для всех экземпляров). Они созданы и существуют ещё до того, как будут созданы экземпляры класса. Соответсвенно, this внутри них не может сам по себе указывать на экземпляр, только если не задать его явно - при вызове через точку, через квадратные скобки, или с помощью call/apply/bind.

Можно объявить методы как стрелочные функции - это современный подход.

class ClassCounter extends React.Component {
...
  increment = () => {
    console.log(this);
    this.setState({ count: this.state.count + 1 });
  };

что практически то же самое, как если бы ты прямо в конструкторе написал

class ClassCounter extends React.Component {
  constructor(props) {
    super(props);
    this.increment = () => {
      console.log(this);
      this.setState({ count: this.state.count + 1 });
    };
  }

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

ну вот сами же ответили

компьютеры обладали малой мощностью

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