#codepen дня

Я, стыдно признаться, очень мало работал с горячими клавишами в вебе. И до недавнего времени даже не мог сказать, в чём отличие which, code и key.

Но для моего пет-проекта пришлось немного покурить тему. И в итоге я наткнулся на прекрасный пример, поясняющий за всю хурму: https://codepen.io/denilsonsa/pen/epmoma

И key, и code, и repeat, и модификаторы, и, собственно, события. Прекрасно.

Конечно же стоит обратить внимание и на MDN: key, code. Там тоже есть интерактивные примеры.

А в пет-проекте было просто прекрасное. Я разрабатываю расширение для Chrome DevTools и никак не мог понять, почему я не могу перехватить стандартные клавиатурные сочетания. Даже чёртов Esc открывал консоль.

А всё оказалось просто: я привык вешать слушатели на window или document, а ребята из Chrome повесили их на document.body. Просто прекрасно.

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

#key #code #js #javascript #hotkeys #keyboard

#заметка дня

Если вы работаете с TypeScript, то не может не замечать, что постоянно типизировать события может быть мучением. Тип события, таргета, значения... Как же быть? Можно как-то перестать повторяться?

Ответ прост, подписчик @glebcha предлагает служебный тип!

import * as React from 'react';

type PaymentMethodKind = 'credit_card' | 'direct_debit'

interface OverrideEventValue<E = HTMLElement, V = string> extends React.ChangeEvent<E> {
target: EventTarget & E & { value: V }
}

const handleChange: React.ComponentProps<'input'>['onChange'] = ({ target }: OverrideEventValue<HTMLInputElement, PaymentMethodKind>) => {
const paymentMethod = target.value;

console.log(paymentMethod);
}

Красиво, декларативно, удобно.

Ну и куда же без ссылки на TS playground.

Ждём контрпредложения в комментариях :)

#ts #typescript #react

#заметка дня

Я обещал про нытьё тимлида. Ну давайте поноем.

Технически, я engineering manager, что чуть больше, но то такое.

Итак, должен ли тимлид/менеджер кодить?

Короткий ответ: да. Но вот что и когда? И вот тут я начинаю сыпаться.

Почему люди (ну, кодеры) становятся тимлидами (или менеджерами)? Потому что, внезапно, они были достаточно хороши в своей работе по мнению вышестоящих менеджеров и/или инженеров.

Что это значит? Что они достигли максимального уровня комфорта, компетентности, если хотите.

Ещё можно сказать, что они освободили место для кодеров получше.

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

Болото кода может засосать глубоко и надолго. А проблемы клиентов, митинги, планирование — никто не отменял. В итоге не получается нормально ни там, ни там.

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

Аврал я помещать в категории не буду. Его наличие означает, что уже всё.

1. Есть свободное окно. Планы закреплены, команда занята, довольна и понимает, что делать, цели намечены — ок, можно продолжать.
2. Ты лучший в том, что собрался делать. Можешь качественно и быстро сделать задачу — вперёд, но не забывай о процессах. Будь примером.
3. Не блокируй критичные узлы. Условно, не надо лезть в аутентификацию, а потом спрыгивать с неё, как будто ничего не было, вешая задачу на кого-то из команды. Не смог спланировать правильно — не начинай.

А вот что точно можно начинать без проблем — это улучшать жизнь команды: собирать аналитику, улучшать сборку, предлагать решения на обсуждение.

Справляюсь ли я с этим на данный момент? Хороший вопрос! Но я пытаюсь, правда :)

#teamlead #manager #code #problems