A big collection of fixes related to translations and TanStack Query, and packages update. #130
Conversation
… and packages update.
| if (facilityId) { | ||
| return User.statusWithFacilityPermissionsQueryOptions(facilityId); | ||
| } | ||
| // If the facility is not available, return statusQueryOptions below, which will fail |
There was a problem hiding this comment.
Nie da się uniknąć niepotrzebnych zapytań, jeśli wiadomo że "fail anyway"?
Też nie widać gdzie i czemu "fail anyway", bo pod spodem nie widzę sprawdzania "facility permissions fields".
There was a problem hiding this comment.
Facility permission fields są w localProps.roles. Więc nigdy nie będzie accessGranted skoro ich nie ma w wyniku (są wszystkie false).
Zwracam disabled query.
There was a problem hiding this comment.
To chyba nadal nie rozumiem, "Return a disabled query, which will be shown as pending"? Pending forever? Dlaczego nie jakiś błąd w takim razie?
There was a problem hiding this comment.
Brak facility jest tutaj stanem przejściowym. Jeżeli wynika z tego że to facility w ogóle nie istnieje no to router pokaże jakąś stronę że not found. Więc tutaj to może wynikać z tego, że facilities się jeszcze nie załadowały, no więc pending. W ogóle to jest przypadek którego mi się w praktyce nie udało nawet uzyskać i próbuję go zrobić bez zbędnego kombinowania i możliwie szybko :) Naprawdę nie warto w to rozwiązanie inwestować moim zdaniem.
There was a problem hiding this comment.
No dobra, ale czyż nie jest najprościej jakieś throw new Error() w takim dziwnym przypadku?
There was a problem hiding this comment.
No nie, bo jednak teoretycznie się to może zdarzyć, jeśli na przykład facilities nie są dostępne, bo się jeszcze ładują, czy coś takiego. To nie jest jakiś twardy error, tylko raczej takie poczekamy, zobaczymy, a póki co nie masz dostępu.
There was a problem hiding this comment.
Ok, po rozmowie na discord lepiej rozumiem, że to komplikacje solidowe z sekwencyjnym query. Może by tu pomogło zrozumieć coś w stylu "// Return disabled query to wait for facilitiesQuery.data"
No i nadal error facilitiesQuery nie jest obsługiwany poprawnie (zawiśnie na loaderze)? Jak nie ma lepszych pomysłów, to albo dwa QueryBarrier albo przynajmniej poproszę TODO albo komentarz że tak jest i trudno bo np. zadowalamy się toastem na takim zawiśniętym loaderze.
There was a problem hiding this comment.
Dodałem podwójne QueryBarrier i wydaje się działać, chociaż może dobrze gdybyś to przeklikał.
Rewrote the logging and toast on error response.
|
|
||
| createEffect( | ||
| // Don't rerun when fields on queries change, just the top level props. | ||
| on([() => props.queries, () => props.ignoreCachedData], ([queries, ignoreCachedData]) => { |
There was a problem hiding this comment.
Właśnie linię wyżej jest wyjaśnienie.
| if (facilityId) { | ||
| return User.statusWithFacilityPermissionsQueryOptions(facilityId); | ||
| } | ||
| // If the facility is not available, return statusQueryOptions below, which will fail |
There was a problem hiding this comment.
Ok, po rozmowie na discord lepiej rozumiem, że to komplikacje solidowe z sekwencyjnym query. Może by tu pomogło zrozumieć coś w stylu "// Return disabled query to wait for facilitiesQuery.data"
No i nadal error facilitiesQuery nie jest obsługiwany poprawnie (zawiśnie na loaderze)? Jak nie ma lepszych pomysłów, to albo dwa QueryBarrier albo przynajmniej poproszę TODO albo komentarz że tak jest i trudno bo np. zadowalamy się toastem na takim zawiśniętym loaderze.
…states. Changed prefetching of queries to not keep the queries active.
No description provided.