Алексей Мартинкевич LEXA_JA

Ещё можно использовать деструктуризацию объекта по отношению к массиву:

const { 3: x, 4: y } = [1, 2, 3, 4, 5];

console.log(x, y); // 4, 5

useRef(new Class()) тоже будет создавать инстансы на каждый рендер. Для useRef нужно писать через if:

const classRef = useRef<Class>();

if (!classRef.current) {
  classRef.current = new Class();
}

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

Если использовать webpack-dev-middleware то (вроде бы) можно сделать это без перезапуска процесса, а просто заставить сработать watcher, что будет немного быстрее и всё in-memory состояние сохраниться. Но если всё уже работет, то смысла переделывать наверное уже нет.

У вебпака есть програмный API, и у webpack-dev-server тоже
соответственно можно поднять свой express и и приделать API для перезапуска. В теории должно быть можно так сделать, но знаю насколько просто.
Мы использовали такое когда в там ещё не было встроенного прокси.

Я ещё иногда использую useState с ленивым инициализатором и без сетера:

const [instance] = useState(() => new Class()) 

Да, я согласен, это довольно слабый аргумент, по сравнению с остальными, но я так понимаю, это основано на отзывах. Хуки заменили сложности с this на замыкания и ссылочное равенство. Ещё часть про "Classes confuse both people and machines" относится к проблемам с минификаторами и typescipt'ом. Поля классов не могут быть минифицированы без проблем и вывод типов хромал, особенно с HOC.

Хуки были созданы для решения проблемы переиспользования логики привязанной к жизненному циклу компонента. До этого использовали HOC и Render props, а ещё раньше — миксины. Проблема HOC — общее пространство имен пропсов, а render props засоряют дерево компонентов и всё это не удобно композировать.

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

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

Официальная мотивация

Потому что браузерам не очень прикольно поддерживать множество различных режимов работы JS. В strict mode зашли изменения, в том числе мешающие оптимизациям и необходимые для ES6+.

Есть уже готовая удобная обертка @testing-library/react-hooks

Относительный url будет относителен странице (html), а не некоторому js-модулю, в котором относительный импорт на другой js-модуль.

es6 модули разрешают пути относительно скрипта, из которого был сделан импорт

// index.html

<script type="module" src="./src/main.js"></script>

// src/main.js
import "./some/module.js"

Если сервер на http://example.com, то запросы будут:
http://example.com/src/main.js
http://example.com/src/some/module.js

Несколько элементов в одном общем контейнере?

Prettier переносит строки в зависимости от длинны. Иногда увеличение\уменьние длины строки на пару символов попадает на брейкпоинт и происходит переформатирование.

Для тестов: EQAYFlAqxFYuWluL9qWMJIEPxVsoaVXAxIWWgAzwDeWWrdE1
Invoice на 3.50: ton://transfer/EQAYFlAqxFYuWluL9qWMJIEPxVsoaVXAxIWWgAzwDeWWrdE1?amount=3500000000

Тольуко у композиции функций немного другая сигнатура:

GHCi>:t (.)
(.) :: (b -> c) -> (a -> b) -> a -> c

Ну у миксинов были проблемы с конфликтами имен и неявными зависимостями между миксинами, поэтому от них отказались в пользу HOC'ов. Еще из плюсов для хуков это возможность подключить один хук несколько раз. Вообще говоря классы в React тоже имеют мало общего с ООП, а о наследовании компонентов вообще упоминать не принято.
Не буду спорить с тем, что принципиально возможно сделать нормальный API и для классов, но в текущей реализации хуки удобнее классов.

Одно из ключевых преимуществ хуков перед классами это возможность создавать переиспользуемые и комбинируемые куски логики. Хуки являются однозначно более удобным решением чем Render Props, и нередко более удобны, чем HOC'и. Именно возможность удобно создавать кастомные хуки является самой мощной фичей хуков. Если честно, я совсем не против API классов, но там была проблемы именно с выделением кусков логики и привязки к конкретному компоненту. Я не совсем представляю как можно решить именно эту проблему через API классов.

Этот оператор не имеет никакого отношения к приведению к boolean. Этот оператор убирает null из типа.

Там есть плагины как для бэка, так и для фронта. React + Apollo. На выходе будут тайпскрипт типы для Graphql + готовые компоненты\хуки для всех query и mutation.

Используем на проекте GraphQL Code Generator, полёт нормальный

Задепрекейчены только componentWill{Mount,ReceiveProps,Update}, классы никуда не уходят.

Они не просто инициальзируются в разном порядке, первый вариант — это объявление метода. Этот метод попадает в прототип. Второй вариант — объявление поля, в которое записывается фунция. Это поле инициализируется в каждом экземпляре класса. Из чего следует еще один забавный момент: если попытаться унаследоваться от такого класса, то через super, такая функция доступна не будет.

В порядке бреда можно полностью вывести тип валидатора из произвольного типа

type Username = string;
type Age = number;
type PhoneNumber = string | number;

interface IUser {
    name: Username;
    age: Age;
    phone: PhoneNumber;
}

type UserJoi = JoiValidtor<IUser>;
/**
 * name: Joi.StringSchema;
 * age: Joi.NumberSchema;
 * phone: Joi.AlternativesSchema;
 */

type ValidatorGuard<T, TARGET_TYPE, VALIDATOR_TYPE> = T extends TARGET_TYPE
    ? VALIDATOR_TYPE
    : never;

type JoiRecord<T> = {
    [K in keyof T]: JoiValidtor<T[K]>
}

type JoiValidtor<T> = IsUnion<T> extends true
    ? Joi.AlternativesSchema
    : ValidatorGuard<T, string, Joi.StringSchema>
    | ValidatorGuard<T, number, Joi.NumberSchema>
    | ValidatorGuard<T, object, JoiRecord<T>>;
// Дописать сюда и все остальные типы

type UnionToIoF<U> =
    (U extends any ? (k: (x: U) => void) => void : never) extends
    ((k: infer I) => void) ? I : never

type UnionPop<U> = UnionToIoF<U> extends { (a: infer A): void; } ? A : never;

type Prepend<U, T extends any[]> =
    ((a: U, ...r: T) => void) extends (...r: infer R) => void ? R : never;

type UnionToTupleRecursively<Union, Result extends any[]> = {
    1: Result;
    0: UnionToTupleRecursively_<Union, UnionPop<Union>, Result>;
}[[Union] extends [never] ? 1 : 0];

type UnionToTupleRecursively_<Union, Element, Result extends any[]> =
    UnionToTupleRecursively<Exclude<Union, Element>, Prepend<Element, Result>>;

type UnionToTuple<U> = UnionToTupleRecursively<U, []>;

type IsUnion<T> = UnionToTuple<T> extends [any, any, ...any[]] ? true : false

Я не совсем понял, а зачем использовать useEffect для загрузки данных в этом случае? Почему бы просто не сделать так:

const App = () => {
  const [name, setName] = useState('');
  const [result, setResult] = useState();

  const clickHandler = useCallback(() => {
    fetch('//example.api/' + name).then((data) => {
      setResult(data.result);
    });
  }, [setResult, name])

  return <div>
    <input onChange={e => setName(e.target.value)}/>
    <input type="submit" value="Check" onClick={clickHandler}/>
    { result && <div>Result: { result }</div> }
  </div>;
}

Суть не в том, будет ли ругаться React или нет, а в том, что-бы избавиться от замыкания. В этот метод всегда будет приходить актуальное значение стейта.

const [state, setState] = useState(0);

useEffect(() => {
  setState(state + 1);  // setState(0 + 1)

  asyncAction().then(() => setState(state + 1); // setState(0 + 1) state все еще 0
});

useEffect(() => {
  setState(st => st + 1);  // setState(0 + 1)

  asyncAction().then(() => setState(st => st + 1); // setState(1 + 1) state уже обновился
});

А вы пробовали передавать в setState функцию вместо значения? Это позволяет избавиться от замыкания данных.

function updater(item) {
  return items => ([...items, item])
}

const [data, setData] = useState([]);

useEffect(() => {
  // ...
  fetchItem()
    .then(item => setData(updater(item)));
  // ...
}, [setData, /* ... */]);

Вообще говоря, в случае с классами тоже можно было попасть на такие проблемы, если распаковать props/state через дестуктуризацию, а потом замкнуть их в коллбэке.

Технически, для обеспечения иммутабельности, можно использовать Object#freeze. Хотя конечно это все равно не будет работать с вложенными объктами по-человечески.