Comment envoyer une action Redux avec un délai d'attente ?

Comment envoyer une action Redux avec timeout ?

Problème :

Je dois mettre à jour l'état de notification de mon application à l'aide d'un mécanisme de délai d'attente. Les notifications sont généralement des erreurs ou des messages. Je dois envoyer une autre action après 5 secondes pour ramener l'état de notification à l'état initial afin que la notification ne soit pas affichée. La raison principale est de fournir une fonctionnalité où les notifications disparaissent automatiquement après 5 secondes.

J'ai essayé d'utiliser setTimeout et de renvoyer une autre action, mais sans succès, et je n'ai trouvé aucune méthode associée en ligne. Je suis prêt à essayer toutes les suggestions.

Réponse :

Vous n'êtes pas obligé de vous limiter à l'habitude d'écrire toutes les opérations dans une bibliothèque de fonctions. Si vous souhaitez utiliser des délais d'attente en JavaScript, utilisez simplement setTimeout. Le même principe s'applique aux actions Redux.

Redux fournit des alternatives pour gérer les événements asynchrones, mais vous ne devez les utiliser que si vous trouvez qu'il y a trop de duplication de code. Sauf si vous rencontrez un tel problème, utilisez simplement les options fournies par le langage et recherchez la solution la plus simple.

Écrivez du code asynchrone en ligne

C'est le moyen le plus simple. Aucune méthode spécifique à Redux n'est utilisée ici.

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

La même opération est effectuée dans le composant connecté :

this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

La seule différence est que le magasin lui-même n'est généralement pas accessible dans le composant connecté, mais est obtenu en injectant accessoires à dispatch() ou créateur d'action spécifique. Mais pour nous, cela ne fait aucune différence.

Si vous ne voulez pas faire de fautes de frappe lors de l'envoi de la même action dans différents composants, vous pouvez extraire le créateur de l'action au lieu d'envoyer l'objet d'action en ligne :

// actions.js
export function showNotification(text) {
  return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
  return { type: 'HIDE_NOTIFICATION' }
}

// component.js
import { showNotification, hideNotification } from '../actions'

this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
  this.props.dispatch(hideNotification())
}, 5000)

Ou, si vous avant Ils ont été liés via connect() :

this.props.showNotification('You just logged in.')
setTimeout(() => {
  this.props.hideNotification()
}, 5000)

Jusqu'à présent, nous n'avons utilisé aucun middleware ou autre concept avancé.

Extraire le créateur d'action asynchrone

La méthode ci-dessus fonctionne bien dans les cas simples, mais vous pouvez rencontrer des problèmes avec elle :

• Cela vous oblige à dupliquer cette logique partout où vous souhaitez afficher la notification.
• S'il est suffisamment rapide pour afficher deux notifications, ces notifications n'auront pas d'identifiant, donc une condition de concurrence se produira. Lorsque le premier délai d'attente expire, il distribue de manière incorrecte un HIDE_NOTIFICATION, masquant prématurément la deuxième notification.

Pour résoudre ces problèmes, vous devez extraire une fonction, centraliser la logique de timeout et dispatcher ces deux opérations. Comme indiqué ci-dessous :

// actions.js
function showNotification(id, text) {
  return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
  return { type: 'HIDE_NOTIFICATION', id }
}

let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
  // 为通知分配 ID，这样 reducer 就可以忽略不当前可见通知的 HIDE_NOTIFICATION。
  // 或者，我们可以存储超时 ID 并调用 clearTimeout()，但是我们仍然需要在一个地方执行此操作。
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

Le composant peut désormais afficher des notifications à l'aide de showNotificationWithTimeout sans avoir à répéter cette logique ou à avoir des conditions de concurrence avec des notifications différentes :

// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')

// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')    

showNotificationWithTimeout() Pourquoi accepte l'envoi comme premier paramètre ? Parce qu'il doit envoyer des opérations au magasin. Les composants ont normalement accès à la répartition, mais comme nous voulons que la fonction externe contrôle l'opération de répartition, nous devons lui donner le contrôle.

Si vous avez exporté une seule boutique à partir d'un module, vous pouvez l'importer et effectuer l'opération d'envoi directement dedans :

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

Cela semble plus simple, mais nous ne recommandons pas cette méthode . La principale raison pour laquelle nous ne l'aimons pas est que cela oblige le magasin à être un singleton. Cela rend la mise en œuvre du rendu côté serveur très difficile. Côté serveur, vous souhaitez que chaque requête ait son propre magasin afin que différents utilisateurs obtiennent des données préchargées différentes.

Un seul magasin rend également les tests plus difficiles. Vous ne pouvez plus vous moquer d'une boutique lors du test des créateurs d'actions car ils font référence à une boutique réelle spécifique exportée depuis un module spécifique. Vous ne pouvez même pas réinitialiser son état en externe.

Ainsi, même si vous pouvez techniquement exporter une seule boutique à partir d'un module, nous vous déconseillons de le faire. Ne faites cela que si vous êtes sûr que votre application n'ajoutera jamais de rendu côté serveur.

Retournez à la version précédente :

this.props.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
setTimeout(() => {
  this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

Cela résout le problème de la logique en double et évite les conditions de concurrence.

Middleware Thunk

Pour les applications simples, la méthode ci-dessus est suffisante. Si cela vous convient, ne vous inquiétez pas du middleware.

Dans les applications plus volumineuses, cependant, vous pouvez rencontrer certains inconvénients.

Par exemple, faire circuler une dépêche semble malheureux. Cela rend plus difficile le découplage des composants de conteneur et de présentation, car tout composant qui envoie des opérations Redux de manière asynchrone comme décrit ci-dessus doit accepter la répartition comme accessoire afin qu'il puisse être transmis davantage. Vous ne pouvez plus utiliser connect() pour lier un créateur d'action car showNotificationWithTimeout() n'est pas vraiment un créateur d'action. Il ne renvoie pas les opérations Redux.

De plus, il peut être fastidieux de se rappeler quelles fonctions sont des créatrices d'actions synchrones (par exemple showNotification()) et lesquelles sont des fonctions d'assistance asynchrones (par exemple showNotificationWithTimeout()). Il faut les utiliser de différentes manières et faire attention à ne pas les confondre.

C'est là que nous trouvons un moyen de "légitimer" la fourniture de ce modèle aux fonctions d'assistance et d'aider Redux à "traiter" ces créateurs d'actions asynchrones comme un cas particulier de créateurs d'actions normaux plutôt que comme une motivation totale pour différentes fonctions.

Si vous insistez toujours et pensez que ce problème existe dans votre propre application, n'hésitez pas à utiliser le middleware Redux Thunk.

En termes simples, Redux Thunk apprend à Redux à reconnaître des types spéciaux d'opérations qui sont en fait des fonctions :

// actions.js
export function showNotification(text) {
  return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
  return { type: 'HIDE_NOTIFICATION' }
}

// component.js
import { showNotification, hideNotification } from '../actions'

this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
  this.props.dispatch(hideNotification())
}, 5000)

Lorsque ce middleware est activé, si vous envoyez une fonction , le middleware Redux Thunk lui transmettra la répartition en tant que paramètre. Il "mange" également de telles actions, alors ne vous inquiétez pas si vos réducteurs reçoivent des arguments de fonction étranges. Vos réducteurs ne recevront que les opérations objet régulières, celles envoyées directement ou, comme nous venons de le décrire, envoyées par les fonctions.

On dirait que c'est inutile, n'est-ce pas ? Pas dans ce cas particulier. Mais cela nous permet de déclarer showNotificationWithTimeout() comme créateur d'action Redux classique :

this.props.showNotification('You just logged in.')
setTimeout(() => {
  this.props.hideNotification()
}, 5000)

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!