fix: persist candidateApps in osreceive state (VO-463) #1190
Conversation
When resetting the state, we keep the candidateApps (e.g. when the user successfully uploads a file or cancels the upload) This is useful to avoid re-fetching the candidate apps when the user starts a new upload after a successful one This is only persisted in the runtime state and not in the persistent storage to avoid keeping the candidate apps when the user closes the app The candidate apps are fetched again when the user opens the app after closing it
|
Je comprends pas comment ça corrige le bug du cancel ? C'est le re-render qui posait problème ? Si oui, pourquoi ? |
non c'était à cause du reset initial state qui enlevait les candidateApps, et ces dernières n'étaient pas refetch à cause du flag useRef() (didCall.current). J'ai enlevé ce flag et j'utilise le state dans ce commit. Je ne refetch jamais les candidateApps dans le cycle de vie de l'application. A priori il n'y a pas de risque de cache obsolète car les candidateApps ne bougent pas fréquemment (voire jamais), et elles sont refetch au lancement de l'app (après kill). ça enlève donc le bouton cancel et également l'erreur "no candidate apps available" qu'on avait vu |
|
Et pourquoi on passe par un hook custom et pas par un useQuery ? Pourquoi on dispatch des |
Parce qu'on veut faire cette query uniquement si l'utilisateur a ouvert/wake l'application avec des fichiers (c'est une requête assez longue). On peut réorganiser avec |
|
On ne veut plus utiliser |
on peut mettre le useQuery dans la vue en question (avec le bouton next), elle est déjà conditionné à apparaitre s'il y a des fichiers, elle peut gérer elle même la query |
🐛 Bug Fixes