Как эффективно применять React Context

const Context = React.createContext<T>(initValue, createContextDispatcher<T>(listeners, equalityFn));

О. Нашёл наконец, про что вы говорили. Спасибо. Я правда ожидал большего, думал там что-то вроде частичной подписки на содержимое контекста.

стейт хранится и изменяется в контексте React — корректно работает в concurrent mode

Это хорошо.

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

Ничего не понял :) Вы про множественные stores?

и чем это плохо??

По большому счёту ничем (кроме "any"). Но проблемы у этого решения, те же что и у redux. Оно работает в обход react-а. Свой собственный observer и setState-ы в цикле. Значит будут те же самые race-condition-ы с другими компонентами, которые используют уже свои контексты. Например у меня много таких было с react-router-м.

Но пока у нас нет нативной поддержки со стороны React выбора у нас всё равно нет. Только такие вот костыли.

а что же по вашему я должен профилировать?? сферического коня в вакууме который ни на что не влияет?

Код который вы сравниваете. Причём в тех условиях которые предполагаются. Какой самый худший сценарий для "прямолинейного решения"? Когда подписок много и 99% из них зря. Условно вы поменяли кол-во like-ов к комментарию. В идеально только 1 условный <CommentLike/> должен дойти до return <div/>. Если дойдут все (скажем 5_000) комментариев, то производительность в сравнении с оптимизированной версией будет вообще ни разу не сопоставима.

А что вы протестировали? Рендер движок? Ну ок, один и тот же рендер движок имеет одну и ту же производительность. Эка новость.

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

Контекст содержит весь store.state. Целиком. Т.е. "отличный результат от предыдущего" это любое изменение стора. Но я полагаю, что вы имеете ввиду именно селекторы из mapStateToProps или mapDispatchToProps. В таком случае это не так.

На всякий случай хочу уточнить, мы с вами обсуждаем одно и то же? Я обсуждаю прямолинейную реализацию, тот код в статье. Т.е. БЕЗ use-context-selection. Обычный { createContext, useContext } из react.

Так вот, то обновление получают те компоненты которые используют useConnect. И они получают их просто исходя из того, что:

<StateContext.Provider value={state}>

и

const state = useContext(StateContext);

Все useMemo уже не играют никакой большой роли, т.к. компонент уже получил render.

Вот ваш код:

const Container = (ownProps) => {
  const props = useConnect(
     mapStateToProps, mapDispatchToProps, ownProps
  );
  return {
    const { propA, propB } = props;

    return <Component propA={propA} propB={propB} />;
  };
});

Сколько в useConnect вы useMemo не используйте, если useConnect уже запущен (а он запущен ввиду useContext), то return <Component propA={propA} propB={propB} /> уже не избежать. Ведь это hook. Он сам часть компонента. Рендер hook-а производится в рамках рендера его родительского компонента.

Или же вы предполагали этот пример показать как HoC аналогичный connect, а не как самостоятельный конечный компонент с бизнес-логикой? Если это так, то я вас просто не понял (но зачем тогда useConnect?).

если вам удается при профилировании профилировать только render — поделитесь как!

Я скорее покажу как убрать из этой связки браузер. Просто возвращайте из всех компонент-листьев null. И браузер уже будет не причём. Сможете профилировать ровно то, что пишете :)