Redux est-il mort ? Pourquoi j'ai exclu Redux de notre application SaaS

?Connectez-vous : https://www.subham.online

?Twitter : https://twitter.com/TheSubhamMaity

---

Il y a quelques mois, j'ai franchi le pas et refactorisé certaines parties d'une application SaaS sur laquelle je travaille depuis un moment. Nous avions Redux là-dedans, faisant son travail, gérant l'état global. Mais quelque chose n'allait pas : la base de code devenait de plus en plus volumineuse et Redux commençait à se sentir... lourd. Vous savez, comme lorsque vous transportez dans votre sac à dos des objets que vous n'avez pas touchés depuis des mois ? C’est ce que j’ai ressenti.
Mais à mesure que notre application grandissait, sa complexité augmentait également. Redux a commencé à ressembler moins à une solution qu’à un problème. Nous écrivions plus de passe-partout que de logique réelle.

? Le dilemme Redux

Un jour, alors que je luttais contre un autre bug lié à Redux, je suis tombé sur React Query. Après quelques recherches, je suis tombé sur React Query. J'ai entendu beaucoup de bruit à ce sujet, mais je n'ai jamais pensé qu'il pourrait remplacer complètement Redux. Ensuite, j'ai essayé.

Avant (avec Redux) :

// Action
const fetchUserData = (userId) => async (dispatch) => {
  dispatch({ type: 'FETCH_USER_REQUEST' });
  try {
    const response = await api.fetchUser(userId);
    dispatch({ type: 'FETCH_USER_SUCCESS', payload: response.data });
  } catch (error) {
    dispatch({ type: 'FETCH_USER_FAILURE', error });
  }
};

// Reducer
const userReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'FETCH_USER_REQUEST':
      return { ...state, loading: true };
    case 'FETCH_USER_SUCCESS':
      return { ...state, loading: false, data: action.payload };
    case 'FETCH_USER_FAILURE':
      return { ...state, loading: false, error: action.error };
    default:
      return state;
  }
};

// Component
const UserProfile = ({ userId, fetchUserData, userData, loading, error }) => {
  useEffect(() => {
    fetchUserData(userId);
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <Error message={error.message} />;
  return <UserInfo user={userData} />;
};

const mapStateToProps = (state) => ({
  userData: state.user.data,
  loading: state.user.loading,
  error: state.user.error,
});

export default connect(mapStateToProps, { fetchUserData })(UserProfile);

Après (avec React Query) :

const useUserData = (userId) => {
  return useQuery(['user', userId], () => api.fetchUser(userId));
};

const UserProfile = ({ userId }) => {
  const { data, isLoading, error } = useUserData(userId);

  if (isLoading) return <Spinner />;
  if (error) return <Error message={error.message} />;
  return <UserInfo user={data} />;
};

export default UserProfile;

Au lieu de récupérer manuellement les données, d'écrire des réducteurs, de répartir les actions, puis de mettre à jour le magasin, React Query a fait l'essentiel du gros du travail pour nous. Associez cela à des hooks personnalisés bien conçus, et nous avions une machine de gestion d’état simple et efficace.

? Mais attendez, Redux est-il vraiment mauvais ?

Maintenant, ne vous méprenez pas. Redux n'est pas le croque-mitaine. C'est un outil puissant qui a sa place. Si vous créez une application avec un état côté client complexe qui doit être partagé entre de nombreux composants non liés, si vous travaillez avec un état profondément imbriqué ou si vous avez besoin d'un contrôle plus explicite sur le flux de votre application mais pour 90 % des cas, notamment pour la gestion de l'état du serveur, les hooks personnalisés React Query sont plus que suffisants.

Alors, pourquoi toute cette agitation ? Parfois, en tant que développeurs, nous tombons dans le piège d’utiliser ce qui nous est familier, même s’il existe de meilleurs outils. C'est ce qui s'est passé avec moi et Redux. J'étais coincé dans mes anciennes habitudes, pensant que Redux était le seul moyen de gérer l'état dans les applications plus volumineuses. Je veux dire, tout Internet disait « Redux ou buste ! » n'est-ce pas ?

? Le rebondissement de l'intrigue

Voici le truc : en supprimant Redux, nous avons en fait rendu notre application PLUS évolutive. Contre-intuitif, non ? Mais réfléchissez-y : avec React Query gérant l’état de notre serveur et les hooks personnalisés gérant l’état local, nous avions une séparation claire des préoccupations. Chaque partie de notre application est devenue plus modulaire et plus facile à raisonner.

? Redux est-il mort ?

Honnêtement, au cours des derniers mois, j'ai vu très peu de cas où React Query ne répondait pas à mes besoins.

Alors, Redux est-il mort ? Peut-être pas, mais ce n’est certainement plus le All-Star qu’il était. Pour gérer l'état du serveur dans les applications React modernes

Alors voilà. Notre voyage de la dépendance à Redux à l'illumination de React Query. Cela n'a pas toujours été facile : il y a eu des moments de doute, des séances de débogage tard dans la nuit et de nombreuses manipulations. Mais au final, ça valait le coup.

Si vous vous sentez embourbé par Redux dans votre propre application, je vous encourage à prendre du recul et à vous demander : en avez-vous vraiment besoin ? Vous pourriez être surpris par la réponse.

parfois moins c'est plus. Surtout lorsqu'il s'agit de gestion de l'État. Maintenant, si vous voulez bien m'excuser, j'ai encore quelques réducteurs à supprimer. Bon codage !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!