G F

Как выявить то самое проблемное место в коде, где добавляется лишний класс к кнопке?

1. Брейкпоинтом браузера

Также можно отследить любые события и манипуляции с DOM
2. Поиск по коду проекта (искать по названию класса). В любой современной IDE это делается за пару секунд
3. Браузерным расширением фреймворка (если таковой используется). Которое покажет название компонента и его искать уже в исходниках проекта

где вы находите такую работу ? как можно платить программисту , даже стажеру 9-10к рублей, он же тупо умрет с голоду.

https://caniuse.com/?search=grid - 95.86%

Практически все, что можно сделать на флексах, можно сделать на гридах. Я такого не встречал. Но, многие вещи, которые легко решаются на гридах, на флексах ты упоришься делать, а делая адаптив упоришься на каждом брейкпоинте. Если бы во флексах была поддержка gap изначально, то флексы были бы офигенными. Но это свойство появилось недавно, и комфортно его использовать можно будет очень нескоро. Повторю, у гридов поддержка браузерами уже 95.86%.

• Белый по светлому не читается. Белый по пестрому - тем более. Голубой по голубому - ох...
  
• Странное смешение шрифтов с засечками и без. Никакой системы в этом не наблюдается. Какую задачу эта разница решает - непонятно.
  
• Очень много разных размеров шрифтов и межбуквенных интервалов. Проблема та же - нет системы.
  
• Отступы везде разные. Внизу их вобще нет. Проблема та же.
  
• Местами намешана информация. Глаза разбегаются. Здесь явно прослеживается идея поэкранного скролла, или чего-то вроде него, но стоит подумать над тем, чтобы каждый экран был о чем-то одном. Первый про то, что это такое (зачем там какие-то характеристики про опыт и духов?), дальше описание сервера (зачем там реклама справа?), магазин вообще спрятался в куче рандомных фактов по краям, я его в первый раз даже не заметил.
  
• Не совсем понятно, как это должно адаптироваться под разные размеры экранов.
  

В целом докапываться можно много к чему, перечислять нет смысла, но общий посыл такой:

1. Обращайте внимание на систему в дизайне. Загуглите, что такое дизайн-система и почему простота и последовательность - это хорошо.
   
2. Думайте больше о доступности и адаптивности. Вы дизайн делаете для пользователей в первую очередь. Красочная картинка вторична.
   
3. Не нужно нагромождать все, как в газете. Это очень редко работает. Управляйте вниманием пользователей, не давайте ему растекаться во все стороны.
   

P.S.: Также в таких проектах всегда нужно быть готовым к диалогу с разработчиком и не допускать требований pixel-perfect по согласованным без него макетам. Это не так сложно сверстать, но вот эти штуки по краям с линиями и кубиками будут генерироваться на лету (для адаптивности). Они не будут 100% соответствовать нарисованному. Также тут так и напрашивается все эти картинки анимировать, как на текущем сайте mtg. Не знаю, как этот стиль называется, но WebGL - наше все. Да и эти кубики я бы сделал неспешно плывущими более-менее вниз с покачиваниями и поворотами... Но это уже следующий шаг. Первое - система в дизайне и доступность.

Facepalm /o

parseInt('1c', 36) === 48
(48).toString(36) === '1c'

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

Зависит от количества игроков и от самой игры.

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

Но если есть какая-то хитрая механика, которая связывает сессии, то это может быть не вариант.

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

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

Самый сложный вариант - это, конечно же, ММО с открытым бесшовным миром. Там тысячи игроков в одном мире, но могут пересекаться со временем, хотя большую часть времени находятся далеко друг от друга и не соприкасаются. Там используются хитрые алгоритмы распределения по серверам. Но если все игроки соберутся в одной точке, то, скорее всего, всё поломается. Слава богу, что маловероятно, что все игроки условного игрового сервера (состоящего из многих физических) захотят собраться в одном месте.

В настройках sass лоадера для вебпака можно указать общий подключаемый файл.
Опция additionalData

Максимально близкое к желаемому это Discriminating Unions

interface ModelOptionRange {
  value: [ number, number ];
  range: true;
}

interface ModelOptionValue {
  value: number;
  range: false;
}

type ModelOption = ModelOptionRange | ModelOptionValue;

function check(v: number, cond: ModelOption): boolean {
  if (cond.range) {
    // тут cond точно типа ModelOptionRange
    const [ min, max ] = cond.value;
    return (min <= v && v <= max);
  } else {
    // а тут ModelOptionValue
    return v === cond.value;
  }
}

песочница

Попробуй так:

type UserWithoutPassword = Omit<User, 'password'> & {
    password?: never
}

По-русски: поле password опционально, и имеет тип never. Т.к. ни одно значение не может быть типа never, единственный способ удовлетворить этому типу — не иметь поля password вообще.

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

class MyComponent<T> {
  @Input() prop: T;
}

В ИТ, как и везде, есть люди, которых в специальность занесло случайно, и просто нытики. Первые страдают потому, что находятся не на своём месте, занимаются неподъёмной для них работой и не могут достичь успеха. Вторые потому, что не страдать просто не могут.

Можно. Задача не на знание языка, а на алгоритмизацию и логическое мышление.

P.S. можно даже математически решить, на самом деле