redux-toolkit | included toolset for efficient Redux development | State Container library

Reducer functions are pure functions, you can't issue the navigation action from the reducer, but you can from the asynchronous action or in the calling component. React hooks are also only valid in React functions or custom hooks.

Asynchronous actions return a Promise. You can chain from the resolved Promise, or await it, and issue the imperative navigation.

The issue is that the route params are always strings and the post id property is a number.

You were already on the right page in the docs. The trick is to not write a completely new baseQuery, but to wrap a custom baseQuery "around" the existing implementation. This examples shows how to do that to get a dynamic baseUrl, which should be very close to what you want to do here.

I'm not allowed to leave a comment yet, so I'll try to answer you question regarding useLazyQuery vs useQuery here:

useQuery - got triggered on render. Retriggered on params change. Returns data from cache if the cache has some valid data. refetch allows to ignore cache, and forces to make a real API call. refetch has no query params, so you'll need to pass them to initial hook call.

useLazyQuery - got triggered firstly on trigger call, expecting the query params to be passed to trigger, and by default will do a real API call. To get the cached data first (if exists) - you'll need to pass the preferCacheValue param to the trigger function as the second param.

So the "rule of thumb" will be to use useQuery by default to fetch data on the component mount, use refetch when you want to make a real API call ignoring the cache.

useLazyQuery - for cases like yours, when you want to make a call only later (ignoring the render stage) calling the "trigger" on some event (like a button click), and remember about the preferCacheValue option for a case when you have a chance to have the response already cached - this will allow making response feels instantaneous.

In our case - useLazyQuery is MUCH relevant, due to you can avoid all that setCurrentPosition => dispatch => useSelector stuff, and pull all that logic just in click handler, where you'll be able to fetch Geolocation.getCurrentPosition() and pass coordinates to trigger function, that where relevant to the click time, not to the time when the component was rendered.

I would suggest following steps:

1. Fetch the posts with getAllPosts via useGetAllPosts

2. Iterate over result items, creating the Post component whatever it should look like, and passing post's id into it. Or the whole post object, up to you.

3. In the Post component call the useGetPost, providing the id, props, from the parent PostsList component

4. In the Post component define a "refrech" button with the handler, which will call refetch function, provided by the useGetPost hook:

Actually, it is exactly the same as the common useQuery's interface. Only one thing worries - seems like you are reading unexisting loading filed, which expected to be isLoading. Besides that, it's straightforward:

The action.payload created by createAction function. These three fields (payload, meta and error) adhere to the specification of Flux Standard Actions.

Payload:

The optional payload property MAY be any type of value. It represents the payload of the action. Any information about the action that is not the type or status of the action should be part of the payload field. By convention, if error is true, the payload SHOULD be an error object. This is akin to rejecting a promise with an error object.

I've apparently misunderstood how react-testing-library works under the hood. You don't even need to use rerender or act at all! Simply using a waitFor with await / async is enough to trigger the on mount logic and subsequent rendering:

Create an error state slice hold the global error and use isRejected matching function to check whether an action is a 'rejected' action creator from the createAsyncThunk promise lifecycle.

E.g.