Почему иногда React/Redux в текущем состоянии give me creeps

React существует достаточно давно, чтобы мажорные изменения в этой библиотеке, не ощущались температурой подогрева кресел разработчиков в холодные зимние вечера (не благодарите за лайфхак). Но Facebook сделали ход конем и в свое время выпустили не мажорную, а минорную версию и тем самым сняли с себя ответственность за нестабильность уже существующих миллионов репозиториев, как вы уже поняли я буду рассказывать про версию 16.8.0, а так как мы почти никогда не используем React без Redux в продакшн репозиторияx, то и про него скажу. 

И сперва давайте поговорим про React. Почему была упомянута нестабильность после внесения “дополнений” 16.8.0, проблема в том что она произошла в головах разработчиков - легким движением руки Facebook сказал нам, знаете, ООП это конечно же хорошо, но функциональный подход лучше. И тут особо ярые и продвинутые ринулись кидать уже существующий подход Statefull Components и Stateless Components и дописывать новыe functional Components с его хуками useState, useCallback, useEffect etc. и только лишь иногда useContext.

Штош, в самих этих 4х функциях я ничего плохого и не вижу, в общем-то:

• Динамическое именование проперти стейта - Fine

• не нужно выстраивать структуру стейта и запоминать ее для обновления - Excellent

• Можно использовать хук для нескольких изолированных экземпляров стейта даже в одном и том же компоненте - Splendid

• А главное  - это не нужно запоминать все примочки с Lifecycle - тут все сразу понятно - срабатывает сразу после рендера, а если добавишь clean-up возвращаемую функцию то она сработает сразу же перед удалением компонента из дерева, чего уже говорить про то что строк кода нужно писать меньше - Amazing (c) Тим Кук
  

И вот, читаешь это и глаз радуется и уже как бы и не злой ты на Фейсбук и тут находишь это (прим. с офф сайта):

import React, { useState, useEffect } from 'react';

function useFriendStatus(friendID) {
  const [isOnline, setIsOnline] = useState(null);

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(friendID, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(friendID, handleStatusChange);
    };
  });

  return isOnline;
}

А теперь давайте этот пример расширим до жизненных реалий (все хуки в разных файлах):

// useFriednStatus.js

import React, { useState, useEffect } from 'react';
import { useDispatch, useSelector } from 'react-redux';
import * as actions from 'actions';
import { getLoggedInUserSelector } from 'selectors';

function useFriendStatus(friendID) {
  const [isOnline, setIsOnline] = useState(null);

  function handleStatusChange(status) {
    setIsOnline(status.isOnline);
  }

  useEffect(() => {
    ChatAPI.subscribeToFriendStatus(friendID, handleStatusChange);
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(friendID, handleStatusChange);
    };
  });

  return isOnline;
}

// useBestFriendNotifier.js

import React, { useState, useEffect } from 'react';
import { useDispatch, useSelector } from 'react-redux';
import * as actions from 'actions';
import { getLoggedInUserSelector } from 'selectors';

function useBestFriendNotifier(currentUserId) {
    const loggedInUser = useSelector(getLoggedInUserSelector);

    const isBestFriendOnline = useFriendStatus(loggedInUser.bestFriendId);
    const dispatch = useDispatch();

    const notifyMeAboutBestFriendActivity = React.useCallback(() => {
        dispatch(actions.notify(isBestFriendOnline));
    }, [isBestFriendOnline]);

    return notifyAboutBestFriendActivity;
}

// Notification.jsx

import { bestFriendOnlineSelector } from 'selectors';

function Notification(({ id }) => {
    const notifier = useBestFriendNotifier(id);
    const isOnline = useSelector(bestFriendOnlineSelector);

    return (
        <p>Your Best friend is { isOnline ? 'Online' : 'Offline' }</p>
    );
});

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

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

Please, do not use more then one level nesting of custom hooks 

И вот у тебя уже в проекте Stateful Componetns поверх Stateless Componetns, а некоторые перекочевали в function Components (правильно, с хуками, которые под Stateful) и просто function Components, а все потому что нам заботливо написали в документации.

We don’t recommend rewriting your existing components overnight but you can start using Hooks in the new ones if you’d like.

И часто не все разработчики, в силу опыта, а точнее его отсутствия видят картину целостно, то есть ты себе сидишь, пишешь рекурсивные вложенные хуки, код знаешь, место при надобности найдешь, да вот время идет, проекты меняются, а на твое место приходят новые разработчики, которые твой код видят в первый раз.
Все это осознание приходит позже, и что оно дает, правильно - новый подход, четвертый, более чистый - с одноуровневыми кастомными хуками, да только старый подход никуда не делся и если не следить за новым разработчиком который видит существующий легаси и думает - ну и так сойдет и через раз пописывает те самые рекурсивные кастомные хуки. А практика показывает - у лида, архитекторов, разработчиков и других людей заинтересованных смотреть пул реквесты и обновлять конвенцию, и так слишком много работы чтобы присматривать за уже состоявшимся и само-организованным участником Skrum команды, и подход будет плодиться.
Единственным решением в этой ситуации я вижу возможную в будущем пометку в офф. документации - чтоб не использовали вложенность больше одного уровня, а еще лучше прописать такую рулу в линтер, чтоб особо пытливые руки не дотянулись.

Ну и пару слов хочется сказать про redux-thunk, та же проблема - вложенные dispatch() в dispatch(), несколько dispatch() вызовов в одном action где один dispatch() может вызывать чистый action with type ... payload, а вот другие иметь больше вложенных dispatch() и даже с TypeScript не всегда удается отследить отправляемый пейлоад:

function App(() => {
    dispatch(actions.init());
});

// actions.ts

export const init = (): ThunkAction<void, RootState, void, AppAction>  =>  {
    return async (dispatch, getState) => {
        try {
            const user = await getUser();
            if (!user) {
                dispatch(setNotLoggedInUserState());
            }

            dispatch(setLoggedInUserState(user));
        } catch (e) {
            dispatch(showErrorModal);
        }
    };
}

const setNotLoggedInUserState =  (): ThunkAction<void, RootState, void, AppAction> => {
    return async (dispatch, getState) => {
        dispatch(setDefaults());
        dispatch(showLoginModal());
    };
}

const setLoggedInUserState = (user): ThunkAction<void, RootState, void, AppAction> => {
    return async (dispatch, getState) => {
        dispatch(wellcomeBackModal(user.name));
    };
}

// ...

Заключение

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