Возврат провайдера реагирующего контекста из пользовательского ответного хука

Question

Я создал настраиваемую ловушку реагирования, которая управляет определенными данными контекста и возвращает Компонент, который оборачивает любого дочернего элемента этим провайдером контекста, как показано в фрагменте кода ниже, мои единственные проблемы:

1 - это хорошая практика или, по крайней мере, можно использовать этот подход, чтобы сохранить эту логику c централизованной

2 - Влияет ли это на производительность приложения в целом

3 - Есть ли другой способ использовать провайдер контекста, сохраняя хук очень абстрактным?

это показывает реализацию моего пользовательского хука, который я также повторно использую для доступа к контексту:

const NotificationsProvider = props => {
  const socket = useSocket();

  const [notifications, setNotifications] = useState<any>([]);
  const [isFetching, setIsFetching] = useState(false);

  ....
  .... implementation
  ....

  return (
    <Provider
      value={{
        setRead,
        notifications,
        unreadCount,
        isFetching
      }}
    >
      {props.children}
    </Provider>
  );
};

function useNotifications() {
  const { setRead, notifications, unreadCount } = useContext(
    NotificationsContext
  );
  return {
    NotificationsProvider,
    setRead,
    notifications,
    unreadCount
  };
}

export default useNotifications;

этот код показывает, как я использую его на своем root компоненте:

function App() {
  const { NotificationsProvider } = useNotifications();
  ....
  ....
  ....
  return (
    <NotificationsProvider>
       ....
    </NotificationsProvider>
  );
}

export default hot(App);

обратите внимание, что я использую провайдера только один раз, чтобы обернуть компонент root (самый верхний контейнер) и повторное использование useNotifications перехвата в дочернем компоненте для доступа к этому провайдеру, цель состоит в том, чтобы добиться максимальной абстракции, чтобы вам не нужно было заботиться о том, где хранятся эти данные или как они являются внутренними. Кроме того, цель компонента - получить доступ к уведомлениям.