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

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

Сам порой думаю, что если уж и заниматься задачами, то лучше интересными также и с технической стороны.

Однако кажется головной боли там тоже больше может быть с нестандартизированными фичами и плохой поддержкой.

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

P.S. Порадовало, что у данной статьи только один тег “backend”)

https://engineering.atspotify.com/2023/05/tv-spatial-navigation/

#devtips #work

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

Заключается он в том, что вы не читаете определенный материал “от корки до корки”, а в первую очередь просто пробегаетесь глазами по содержанию и темам.

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

Если же пробежавшись по верхам вам ничего не интересно — то лучше отложить и поизучать что-то другое.

Лично я данную технику применяю чаще со статьями, так как книги слушаю в аудио версии.

Но с книгами тоже можно сначала читать выжимки, и если уже все понравилось — то переходят к полной версии.

Да и в целом не знаю, почему я привязался к книгам и статьям. Так можно поступать с любым материалом).

#devtips #learning

При общении с подписчиками часто вижу, что они не довольны своим развитием.

И зачастую причиной плато является плохая работа.

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

Почему?

Да по той просто причине, что это большая редкость.

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

О данной проблеме знаю не понаслышке. Даже помню пару офферов не принимал, потому что я хотел, чтобы были супер-опытные коллеги.

Наверное окончательно все на свои места встало, когда я попал в Яндекс. Где как не там должны быть эти супер разрабы?

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

Да и в конце концов вас никто нянчить же не будет. Максимум совет где-то даст либо подскажет более хорошее решение.

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

Так что не стоит совершать мои же ошибки и винить внешние обстоятельства.

А вместо крутых коллег лучше подыскать сложные задачи, которые вы на данный момент не знаете, как решать.

#devtips #work

Всем привет!

Под мои недавним постом о развитии на работе было много обсуждений. Однако хотел бы сфокусировать свое внимание на self review (само проверке) кода.

Для тех, кто никогда так не делал, это все может показаться странным. Кажется, на что там смотреть, если я и так все помню?

Однако если научится снимать менять роль и смотреть на свой pull request со стороны — то можно заметить очень много недочетов и избавится от лишних комментариев.

Наверное самым простым способом будет провести ревью где-то через день. А не сразу после завершения задачи.

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

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

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

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

Да, не всегда стоит делать хорошое решение сразу, но в любом случае на свои ошибки посмотреть можно).

В целом, навык самоанализа полезен во всех сферах жизни.

Сам недавно понял, что всем даю такой совет для написания кода, но почему-то не применяю тот же принцип для улучшения своих видео.

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

#devtips #work

Сегодня узнал интересный момент, касательно анимаций.

Наверное все слышали, что для триггера анимаций нужно использовать вложенные requestAnimationFrame или же производить forced reflow, чтобы браузер понял об изменении стилей.

Например, такой код не будет анимировать ничего:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  div.style.height = "500px";
}

А такой:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  requestAnimationFrame(() => {
    requestAnimationFrame(() => {
      div.style.height = "500px";
    });
  });
}

Или такой:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  div.getBoundingClientRect();

  div.style.height = "500px";
}

Будут.

Я всегда думал, что это правило применимо для всех свойств. Но кажется, что это относится только к тем, которые триггерят reflow.

Например, после запуска вот этого кода, у вас также сработает анимация.
```
function animate() {
const div = document.querySelector("item");

div.style.color = "red";
div.style.transition = "all 1s ease";

div.style.color = "white";
}
```
Выглядит так, что браузер просто пытается оптимизировать лишние reflow, поэтому не запускает анимации для свойств, которые на него воздействуют.

Опять же, это просто предположения, но хочется подробнее про это все узнать. Может кто-то знает, с чем это связано?

UPD: В комментах @senheleet подсказал, что с color работает все, так как у нас по дефолту всегда есть какое-то значение. А с height по дефолту значение auto и от него нельзя начать анимацию.

#devtips #js

Сегодня смотрел, что нового происходит в мире JS.

Самое интересное, что я нашел — это выход nest.js v10 и svelte v4.

По поводу nest много сказать не могу, так как я почти не писал на нем.

А вот улучшения по размеру конечного бандла от свелта не плохи, учитывая то, что и так output был у него значительно меньше того же реакт (но меня больше удивило уменьшение размера самого пакета в 4 раза).

Хотя, кажется это только меня и заботило)

Если есть что-то интересное — тоже делитесь в комментариях.

https://svelte.dev/blog/svelte-4
https://trilon.io/blog/nestjs-10-is-now-available

#devtips #js

Сегодня помогал человеку с реализацией draggable canvas (по типу миро, но на html).

Столкнулся с проблемой, когда код внутри setState колбэка вызывался 2 раза.

Код выглядел примерно так:

setPosition(position => {
const deltaX = e.clientX - prevMousePosition.x;
const deltaY = e.clientY - prevMousePosition.y;
prevMousePosition = {
x: e.clientX,
y: e.clientY,
}

return {
x: position.x + deltaX / scale,
y: position.y + deltaY / scale,
}

В итоге при первом вызове стейт вставал в правильное значение, а при втором — все сбрасывалось, так как prevMousePosition был уже таким же, что и clientX/clientY из ивента.

Благо из-за серых логов быстро смог понять, в чем причина. Но все равно выглядит очень странно.

Да, по задумке колбэк должен быть pure function. Но почему нету никакого лога о том, что второй вызов выдал другой результат?

В общем, при обновлении стейта будьте внимательнее.

#devtips #react

Полезный совет для тех, кто хочет разобраться в библиотеке, смотря на исходный код.

Проще всего будет разобраться в основной задумке и понять, как все работает, смотря на первые версии.

Кода там намного меньше, так как еще не успели покрыть все возможные краевые случаи, работу в iframe и баги старых браузеров.

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

Сам сегодня при подготовке к новому видео зашел в версию React 0.3.0 и был удивлен тем, как там мало кода и как легко его читать.

В общем, если хотите начать разбираться в кишках вашего инструмента, то можно начать со старых версий.

#devtips #opensource

Пока все про using говорят, команда TS подвезла нам очень классные фичи для грядущей версии 5.2.

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

Уже давно не припомню, чтобы в одном релизе сразу столько болей моих правили (последнее что помню — это 4.1).

https://devblogs.microsoft.com/typescript/announcing-typescript-5-2-beta/#decorator-metadata

#devtips #typescript

Одна важная вещь, которую нужно учитывать, если вы предпочитаете использовать типы вместо интерфейсов в TS - это отличие type intersection (`AType & BType`) от наследования интерфейсов.

Давайте для простоты понимания сразу взглянем на пример:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & BaseModelType;

type TestType = MyModelType['test'];
//    ^?
// { a: number } & string;

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends BaseModelInterface {
//        ^^^^^^^^^^^^^^^^
// Interface 'MyModelInterface' incorrectly extends interface 'BaseModelInterface'.
//   Types of property 'test' are incompatible.
//     Type '{ a: number; }' is not assignable to type 'string'.ts(2430)
    test:  a: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

Как вы можете видеть, в кейсе с типами у нас нету overriding'а, то есть тип каждого из свойств тоже объединяется в единый результат, даже если они не совместимы.

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

Решение у 2-х проблем одинаковое — использование Omit:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & Omit<BaseModelType, 'test'>;

type TestType = MyModelType['test'];
//    ^?
// { a: number };

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends Omit<BaseModelInterface, 'test'> {
    test: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

Не говорю, что нужно использовать одно или другое (я считаю тут просто нужно договориться на уровне проекта), но наследование у интерфейсов по лучше.

#devtips #typescript