Mikhail Osher

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

Поиск? Нет. Всем плевать на вышку, когда кандидат имеет хорошие знания для той позиции, на которую устраивается. Ни один ВУЗ не научит тому, что познается на практике.

Однако если захотите переехать в Европу или США со стандартным трудоустройством (как employee, а не как contractor), то там уже вышка вполне нужна для L1 / Blue Card тупо по юридически-миграционным причинам.

Набросал на коленке, просто показать идею

const sectionMain = document.querySelector('.main-section');

sectionMain.addEventListener('click', (event) => {
  if (event.target.classList.contains('element')) {
    sectionMain.classList.toggle('active');
  }
});

upstream это название для remote, зачастую в open-source & fork контексте.

Дефолтный ремоут обычно называется origin, когда мы клонируем репозиторий локально.
Однако когда имеем дело с форками, то надо добавлять другие ремоуты. И вот оригинальный ремоут, с которого мы делали форк, как раз называют upstream.

Чтиво

https://git-scm.com/book/en/v2/Git-Basics-Working-...
https://www.atlassian.com/git/tutorials/syncing
https://www.atlassian.com/git/tutorials/git-forks-...

Я бы в тесте просто нашел burgericon, кликнул по нему, и затем уже писал expect ниже.
Либо создайте опциональный проп initialOpen, который передайте в useState.
Это вполне себе нормальная практика иметь такие опциональные props (а-ля dependency injection), чтобы легко в тестах мокать было. Например, api всякие и прочее.

Оффтоп: насколько я помню, методы getBy* кидают ошибку, если элемент не найден, в отличие от findBy* => можно не проверять результат через toBeinTheDocument, а просто писать одну строчку screen.getBy*("selector")

//edit

Как подметили в комментах, то можно и для findBy не делать проверку, ибо я перепутал findBy с queryBy.

Array.prototype.sort specification

Однако там сложным языком описано.
На MDN в разделе Description описаны нюансы, которые могут быть полезны.

Если точно знаем, что люди не будут специально творить пакости, и не вариант заводить разных Windows пользователей, то по идее можно попробовать следующим образом.

- каждый юзер должен иметь свой github аккаунт
- заводим на машине на каждого юзера свой ключ
- юзеры должны заимпортить свой ключ в настройки github
- создаем каждому пользователю свою рабочую папку (даже если они будут работать с одним и тем же репозиторием)
- создаем конфиги для каждой папки

Вот как, например, выглядят мои конфиги. Глобальный конфиг - для личных проектов. И есть еще отдельные конфиги на каждого работодателя. У меня все проекты лежат в ~/Projects, однако есть на каждое место работы подпапка ~/Projects/companyname, для которой использую кастомные настройки.





В Вашем случае, надо будет подменять IdentityFile для git+ssh подключения. Ответов в интернете на это вагон. Я бы в эти кастомные конфиги добавил core.sshCommand, который уже будет использовать правильный IdentityFile для каждого юзера. Будет полезным почитать ответы и комментарии https://superuser.com/questions/232373/how-to-tell...

useMatch() возвращает объект match
useParams() возвращает объект match.params

Раньше все данные роутинг компонента насильно прокидывались пропами в компонент, даже когда компоненту этого не нужно было знать. Теперь это заменили хуками (заодно изменив сигнатуру роутера с Route path="xxx" component={MyPage} на Route path="xxx" element={<MyPage />})

Выглядит, как взять register из useForm, и прокинуть его через контекст всем дочерним компонентам, чтобы они в свою очередь вызывали register для нужных компонентов.

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

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

Поэтому, идем на собеседования в компании, в которых действительно было бы интересно попробовать поработать. Даже если компания выглядит интересно, но боимся, что не возьмут - все равно идем, и не боимся фейла. Проходим собесы, получаем офферы, где получится. Если предложили весьма больше денег, то можно смело уволняться, и идти на новое место. Если предложили ± те же деньги, то уже надо выбирать по коллективу/начальству/задачам и другим важным факторам (отпуска, больничные, дни без справок, переносы рабочих дней). Через пару лет повторяем цикл.

https://codesandbox.io/s/angry-booth-4pinuu?file=/...

const draggable = document.getElementById("draggable");

let isDragging = true;

draggable.addEventListener("touchstart", () => {
  isDragging = true;
});

draggable.addEventListener("touchend", () => {
  isDragging = false;
});

draggable.addEventListener("touchmove", (event) => {
  if (isDragging) {
    const { pageX, pageY } = event.touches[0];
    draggable.style.top = pageY + "px";
    draggable.style.left = pageX + "px";
  }
});

Да, можно обратиться. Для этого надо запустить процесс на 80 порту, что, обычно, требует root права.
Я с вебпаком работаю года так с 2013-14, и подобную хрень приходилось делать пару раз, когда были жуткие ограничения по разработке. В целом, не заморачивайтесь, и изучите, как работает webpack, чтобы не паниковать в таких моментах. Советую этот курс (он может быть и outdated, однако очень хорошо описывает принципы работы).

По поводу "где файлы" - https://webpack.js.org/guides/development/

webpack-dev-server doesn't write any output files after compiling. Instead, it keeps bundle files in memory and serves them as if they were real files mounted at the server's root path. If your page expects to find the bundle files on a different path, you can change this with the devMiddleware.publicPath option in the dev server's configuration.

Я бы попробовал повесить observer на src аттрибут у iframe. Однако слабо верю, что сработает, но всё же можно попробовать.

Проблема в том, что тип wwCodes при таком объявлении будет равен

{ 0: string, 1: string, 2: string, 3: string, 45: string }

, но никак не { [key: number]: string }, который ожидали бы.

Зависит от условия задачи.

wwCodes статически захардкожен в коде и не будет меняться на протяжении работы скрипта?
useState<keyof typeof wwCodes>

wwCodes - это некий generic объект, который мы получим извне (props, hooks, context), но мы предполагаем такую структуру?

type WwCodes = Record<number, string | undefined>
const wwCodes: WwCodes = ...