ivan0512

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

Исходя из этого - сначала ревью.

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

Поэтому сначала ревью, потом тестирование.

Что стоит использовать type или интерфейс?

Что хотите

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

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

В любом случае - однообразие - это хорошо. Что вас к нему приближает, так и пишите.

Extract
type Result = Extract<Union, { type: 1 }>

Знание реакта это большой плюс но проблема в том что есть серьезные различия веба и натива. Вам как минимум надо знать основные компоненты например FlatList где его применяют его обязательные свойства и как с ним работать. Не обязательно знать все атрибуты но обязательно вы должны знать. Естественно никто вам не запретит лезть в доку но думаю на собеседовании если вы скажете обязательные свойства это будет плюсом. Еще большим плюсом будет понимание кода java и object c (это вам понадобиться рано или поздно и в зависимости на какой уровень вас берут могут спросить).

Я не фронтенд разработчик, но отпишусь.
Думаю, тут важен контекст, для чего изучать.
Для общего развития - изучать! Но тогда имеет смысл изучить чуточку андроида, и пробовать писать код, часть которого будет шариться на бек, фронт и андроид(в идеале ещё iOS).
Для просто замены TS - имхо, не стоит. Нет никакой мотивации и профита переходить на котлин только во фронтенде. Насколько я знаю, там есть ненулевые накладные расходы, которые только удобство языка, вроде как, не перекрывает.

Сейчас все переходят в андроиде на котлин, потому что на JVM накладных расходов довольно мало, а профит по сравнению с Java очень большой(после котлина реально не хочется возвращаться). Кроме того, гугл сделал котлин официальным языком. Нам этого мало и мы сейчас делаем некоторые фичи кроссплатформенными, общий код с iOS. Пока что это довольно больно, очень много граблей собираем, всё там довольно сыровато.

Вы неправильно поняли. Просто читайте | как "или", а & - как "и".

number | string значит, что переменная содержит либо число, либо строку.

number &string значит, что переменая будет и числом и строкой одновременно. И не важно, как это реализовано, и реализуемо ли в принципе (нет).

Вот соответствующий баг. А вот объяснение почему это не баг.

В общем случае пустой массив имеет тип never[]. Но в простом случае TypeScript умеет выводить тип изначально пустого массива по последующим операциям над ним. Типа push.

Так что реально тип test1 из вашего примера станет string[], как только будет "зафиксирован". Например, возвращён из функции или назначен в другую переменную.

Так что следующий код будет работать:

function buildArray() {
  const test1 = []; // тут будет any[]
  test1.push('str');
  test1.push(1);
}
const array = buildArray(); // тип (string | number)[]

А вот такой - уже нет

const test1 = []; // тут будет any[]
test1.push('');
const test2 = test1;
test2.push(2); // Argument of type '2' is not assignable to parameter of type 'string'.