-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EES-5542 Maps fetching/rendering boundaries for datasets #5423
base: dev
Are you sure you want to change the base?
Conversation
const queryClient = useQueryClient(); | ||
// add existing geoJson to cache, avoiding double fetching | ||
queryClient.setQueryData( | ||
['mapLocationGeoJson', releaseId, dataBlockParentId, boundaryLevel], | ||
meta.locations, | ||
); | ||
|
||
const { data: locations, isFetching: isFetchingGeoJson } = useQuery< | ||
LocationFilter[] | ||
>({ | ||
queryKey: [ | ||
'mapLocationGeoJson', | ||
releaseId, | ||
dataBlockParentId, | ||
selectedBoundaryLevel, | ||
], | ||
queryFn: async () => { | ||
return mapFullTableMetaLocations( | ||
await tableBuilderService.getLocationGeoJson( | ||
releaseId, | ||
dataBlockParentId, | ||
selectedBoundaryLevel, | ||
), | ||
); | ||
}, | ||
staleTime: Infinity, | ||
cacheTime: Infinity, | ||
keepPreviousData: true, | ||
refetchOnWindowFocus: false, | ||
refetchOnMount: false, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactor into tableBuilderQueries
As discussed, we should refactor the GeoJSON fetching into a new getLocationGeoJson
query key in tableBuilderQueries
.
As part of this, we'll also need to refactor the current implementation of tableBuilderQueries.getDataBlockTable
so that the table data is fetched independently of the GeoJSON so that these become two separate queries.
It might also be a good idea to keep the mapFullTable
and mapFullTableMetaLocations
inside the respective query functions so that we don't need to call them again, but will leave that with you.
Restructuring the data fetching
As we also discussed, it's probably cleaner to hoist the GeoJSON fetching into the parent component and use a callback to pass the boundary level back up whenever it changes.
I'll leave it to you to figure out the details, but it might be a little bit more involved in the chart builder. Lemme know if there's any complications.
The main caveat I can see is around the loading state when the boundary level is being changed. It might be nice if we can avoid having to pass this into MapBlock
(from the parent) and control this from within MapBlock
itself. An async callback might help with this i.e.
interface MapBlockProps {
// ...
onBoundaryLevelChange: (boundaryLevel: number) => Promise<void>;
}
// When boundary level is being changed
setBoundaryLevelChanging(true);
await onBoundaryLevelChange(boundaryLevel);
setBoundaryLevelChanging(false);
src/explore-education-statistics-common/src/modules/charts/components/MapBlock.tsx
Outdated
Show resolved
Hide resolved
src/explore-education-statistics-common/src/modules/charts/components/MapBlock.tsx
Show resolved
Hide resolved
src/explore-education-statistics-common/src/modules/charts/components/MapBlock.tsx
Outdated
Show resolved
Hide resolved
src/explore-education-statistics-common/src/modules/charts/components/MapGeoJSON.tsx
Outdated
Show resolved
Hide resolved
src/explore-education-statistics-common/src/modules/table-tool/utils/mapFullTableMeta.ts
Outdated
Show resolved
Hide resolved
...xplore-education-statistics-common/src/modules/charts/components/__tests__/MapBlock.test.tsx
Show resolved
Hide resolved
...xplore-education-statistics-common/src/modules/charts/components/__tests__/MapBlock.test.tsx
Outdated
Show resolved
Hide resolved
expect(loadingSpinner).toHaveTextContent( | ||
'fetching geometry for data selection', | ||
); | ||
expect(tableBuilderService.getLocationGeoJson).toHaveBeenCalled(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should assert what it's been called with
test('selecting data set with different boundary level fetches different boundary geo-JSON', async () => { | ||
tableBuilderService.getLocationGeoJson.mockResolvedValueOnce( | ||
testMapTableData.subjectMeta.locations, | ||
); // EES-5718 need to return different location geoJson for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment seems to just trail off? Not sure what it's trying to say
src/explore-education-statistics-common/src/modules/charts/components/ChartRenderer.tsx
Outdated
Show resolved
Hide resolved
3122129
to
c0c6c08
Compare
7ecb527
to
5db0cc7
Compare
…onents with callbacks
…ove map component
1594334
to
8255bad
Compare
8255bad
to
8cd2437
Compare
Setting map charts to fetch location geo JSON for data sets with boundary levels set.
This has been setup by:
releaseId
&dataBlockParentId
props into MapBlockuseQuery
to handle fetching location geo JSON based on data set input selectionuseQuery
cache is initialised with existing subject meta location data to avoid duplicate callsuseQuery
as it stands and is set to not refetch on alt-tab or stale data, as the response is extremely unlikely to change