• Что должно быть сначала код ревью или тестирование?

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

    Исходя из этого - сначала ревью.
    Ответ написан
  • Что должно быть сначала код ревью или тестирование?

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

    Поэтому сначала ревью, потом тестирование.
    Ответ написан
  • Используете ли вы scoped стили при использовании vue?

    @KindredSpirit
    Прежде всего - слабая инкапсуляция. Точнее, ее почти нет. scoped-стили инжектят в целевой DOM-элемент атрибут с хэшем, что никак не защищает от внешних классов с тем же названием.
    То есть, если у вас scoped-класс example с color: red, на выходе будет что-то вроде:
    .example[data-v-hsfg3e3] {
      color: red;
    }

    И если в другом компоненте без скоупов или в глобальных стилях есть класс example с background-color: red, у вас проблемы.

    В целом, не вижу причин использовать scoped при наличии из коробки css-модулей, в которых этих недостатков нет.
    Ответ написан
  • Что стоит использовать type или интерфейс?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Что стоит использовать type или интерфейс?

    Что хотите

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

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

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

    Aetae
    @Aetae
    Тлен
    Мысли простые на самом деле: зри в корень.
    Интерфейсы используй для описания интерфейсов, типы используй для описания типов.
    И нет, это не одно и тоже.
    Если утрировать: интерфейс - это описание структуры данных, встречающееся на стыке взаимодействия компонентов системы или разных систем, в основном используется только на этом самом стыке; тип - это внутренние сущности которыми оперирует система и которые встречаются повсеместно.
    Ответ написан
  • Как выровнять иконку по центру в кнопке?

    alekseyHunter
    @alekseyHunter
    Android developer
    Сделайте CardView и расположите ImageView с TextView. Добавьте OnClickListener, ripple эффект, и будет вам кастомная кнопка.
    Ответ написан
  • Что нужно знать, чтобы работать с react native?

    RomReed
    @RomReed
    JavaScript, React js, ReactNative, Redux, Firebase
    Знание реакта это большой плюс но проблема в том что есть серьезные различия веба и натива. Вам как минимум надо знать основные компоненты например FlatList где его применяют его обязательные свойства и как с ним работать. Не обязательно знать все атрибуты но обязательно вы должны знать. Естественно никто вам не запретит лезть в доку но думаю на собеседовании если вы скажете обязательные свойства это будет плюсом. Еще большим плюсом будет понимание кода java и object c (это вам понадобиться рано или поздно и в зависимости на какой уровень вас берут могут спросить).
    Ответ написан
  • Изучать ли kotlin frontend разрабочику?

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

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

    Bavashi
    @Bavashi
    На мой взгляд, продолжить изучение ноды стоит через создание клиент-серверного проекта и максимально задействовать апи из документации, то есть возможности и фичи этой платформы. Это будет полезно не только как практика, но и пополнит ваше портфолио, что будет только плюсом на собеседовании, на которых редко дотошно и целиком спрашивают знание всей документации, потому что важнее то, как вы умеете разбираться с чем-то новым, то есть как умеете изучать материал и решать поставленную задачу. А курсов все же скорее всего будет недостаточно, даже несмотря на ваш опыт. Все-таки практика может вызвать вопросы, о которых вы не задумывались или можете столкнуться с моментами, которые не так поняли. Также можете почитать книжки по ноде, например "Стек MEAN" Саймон Холмс.
    Ответ написан
  • Нужно ли от и до изучать документацию nodejs?

    @MagicMight
    Уровень мидла и предполагает знание технологии не на уровне "знаю, что это работает" а "знаю, как это работает".
    Документацию стоит прочитать хотя бы по диагонали, чтобы чисто ассоциативно вспоминать во время решения задач какие-то тонкости и рекомендации, и, понимая, как оно работает под капотом, знать что гуглить в спорных моментах
    Ответ написан
  • Нужно ли от и до изучать документацию nodejs?

    Robur
    @Robur
    Знаю больше чем это необходимо
    То есть лучше относиться к большей части разделов как к апишке и иногда заглядывать

    Да. Это и есть апишка, которую nodejs предоставляет в своей среде выполнения.
    Но общее понимание что там есть и что где искать - нужно, плюс базовые вещи конечно надо знать, но их вы найдете и запомните в любом случае. А так же как нода работает в принципе - тоже.
    Ответ написан
  • Какая логика работы intersection и union типов?

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

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

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

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

    В общем случае пустой массив имеет тип 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'.
    Ответ написан
  • Можно ли указать какие компоненты можно передать в children?

    miraage
    @miraage
    В children можно передать что угодно. Вопрос в том, как компонент будет это использовать.
    Например, в паттерне Render Props, children передают, как функцию.

    // edit-ответ на коммент

    Как-то так должно работать.
    import React from 'react';
    
    interface MyComponentProps {
      children: (items: string[]) => void;
      regexp: RegExp;
      items: string[];
    }
    
    export const MyComponent: React.FC<MyComponentProps> = ({ children, items, regexp }) => {
      return children(items.filter(item => regexp.test(item)));
    }
    Ответ написан