profesor08

classList.toggle

Ну, создай `div` и вставь в него контент, потом достань обратно. Браузер сам позаботится о тегах.

<script type="module" src="script/script.js"></script>

В самый низ

1. В label не должно быть блочных элементов
2. В label не должно быть ссылок

В приведенном коде нарушаются оба пункта. Надо сделать так, чтоб в label не было подобных элементов.

Вывод: надо обновить требования, чтоб они соответствовали возможностям и спецификации HTML. Если потребуется доработать дизайн.

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

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

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

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

Наверняка надо установить подходящий плагин. Просто вбей eslint в поиск в разделе плагинов.

Если надо описать некоторый перечень значений, то type:

type ResponseStatus = "error" | "success";

Если надо описать объект, то intefcace:

interface ApiResponse {
    status: ResponseStatus;
}

И никто не запрещает написать через type:

namespace Api {
    type Status = "error" | "success";

    type Response = {
        status: Status;
    };
}

throw бросит исключение, которое ты можешь обработать когда-то там потом, и гарантирует, что все дальнейшее исполнение будет прервано.

reject не бросает исключения и исполнение кода не прервется. Исключение будет выброшено когда-то там потом, когда промис этого захочет.

new Promise((resolve, reject) => {
  reject("reject msg");
  console.log("wtf?????");
})

Как восстановить файл css?

1. Удаляешь atom, устанавливаешь vscode.
2. Пишешь стили заново. Второй раз будет проще.

Нет, не нужен. Typescript самостоятельно обработает твой код таким образом, чтоб он соответствовал нужной тебе спецификации. Делает быстро, делает качественно, и не позволит скомпилить код с ошибками.

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

Например, если у тебя type="text", то выглядеть будет как белый прямоугольник с рамкой, в который ты можешь печать текст и получить этот текст в атрибуте value

Если у тебя type="number", то выглядеть будет несколько иначе, появятся кнопочки. Вводить можно будет только цифры. Начинают работать дополнительные атрибуты, которые ограничивают диапазон вводимого числа, шаг инкремента при нажатии на стрелки, а так-же появляется дополнительное форматирование.

Если у тебя type="file", то вводить ты туда ничего не можешь, в value будет имя выбранного файла. А через свойство files можно будет получить доступ к выбранным файлам. Так-же начнет работать атрибут accept.

И так для каждого типа инпута.

Так что тут можно сказать лишь то, что сказать что атрибут type задает тип инпута, это как ничего не сказать.

Преподаватель говорит, что атрибут type у input задаёт тип данных для этого элемента.

Не он не прав, в зависимости от типа, браузер отображает разные элементы. И взаимодействовать с инпутами надо по разному.

Но мне кажется, что атрибут type задаёт не тип данных, а лишь формат ввода данных.

Учитывая выше написанное, это не так.

<BrowserRouter basename="/">

webpack не обфусцирует, вноси столько правок, сколько нужно.

and => &&
or => ||

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

Вся сложность заключается в том, чтоб узнать именно высоту содержимого. Тут поможет scrollHeight. Но если растягивать постоянно, то и значение будет расти, а значит если удалить текст, то блок не уменьшится. Нужен какой-то трюк, чтоб сбросить его к нормальному, задав высоту 0. Юзер ничего не заметит и магия сработает.

const textarea = document.querySelector<HTMLTextAreaElement>("textarea");
const minHeight = 60;
const maxHeight = 260;

const constrain = (n: number, low: number, high: number) => {
  return Math.max(Math.min(n, high), low);
};

if (textarea !== null) {
  textarea.addEventListener("input", () => {
    textarea.style.setProperty("height", "0");
    textarea.style.setProperty(
      "height",
      constrain(textarea.scrollHeight, minHeight, maxHeight) + "px",
    );
  });
}

P.S. размеры внутренних отступов и рамок надо будет тоже учитывать, но там все просто.