The default behavior of useShow hook

[vinclou]

Suppose you have a Show page, but you want to pass a custom resourceParam

const { showId } = useShow<Example>({ resource: 'api/V1/Example' })

By doing so you override the default id that useShow grabs from the URL so the fetch request won't proceed.

Is that the default intended behavior?

I was hesitant to submit a bug ticket as it might be a feature. It seemed unintuitive to me, that it would override id if you pass a different resource name.

My workaround is this:

const { useParams } = useRouterContext()
const { id } = useParams<ResourceRouterParams>()	
const { queryResult, showId } = useShow<Example>({ resource: 'api/V1/Example', id: id })

When you explicitly pass the id it would work, but what you end up with is calling useParams twice, once internally by useShow and then at component level

And I'm able to fetch the data, I looked at useShow internal code link

const defaultId = !resourceFromProp || resourceFromProp === routeResourceName ? id ?? idFromRoute : id

Default would not be set if you pass a custom resource

[aliemir]

Hey @vinclou, that condition is added to support the cases like you use the useShow hook twice, one for using it to fetch the data from url params (like posts/1) and one for fetching the categories/15 data which id is coming from the response of posts/1.

The condition works as an enable/disable switch for useShow to handle asynchronously using the id 15 for categories resource.

We've recently had a discussion on updating this logic since it's limiting the use cases and actually causing a confusion on when to use useShow and when to use useOne. I think we will cover more cases by allowing id only and resource only prop changes and leaving categories/15 calls in posts/1 page to useOne.

I wonder about your use case though, just a wild guess; can you achieve what you are trying to do by just using options: { route: 'my-custom-route' } to your resource (api/v1/example)?

[vinclou]

I actually need the id, my browser window location is not in sync with dataProvider, because it doesn't make much sense for me due to the API architecture we have to sync them.

So whenever I find myself always explicitly specifying the resource string, I'm sure there's a better solution, yet for now I'm avoiding the creation of any abstractions. I just started this week to actively use Refine for internal tool redesign, and I want to understand the basics first before committing to any abstractions.

[vinclou]

Oh wait, I think I misread what you said.

I wonder about your use case though, just a wild guess; can you achieve what you are trying to do by just using options: { route: 'my-custom-route' } to your resource (api/v1/example)?

Does options object relate to custom pages and definitions in routerProvider?

[aliemir]

It was just a guess but it seemed like you were trying to use refine pages but since api/v1/example is a good api route but not a good looking page route you end up creating a custom page with a cleaner route you wanted; if this is the case (still just a wild guess);

you can use it like

<Refine
    resources={[
        {
            name: "api/v1/example",
            list: YourListPageComponent,
            options: {
                route: "my-good-looking-route",
                label: "My Good Looking Label",
            },
        }
    ]}
    {/* ... */}
/>

So your list component will render in /my-good-looking-route instead of /api-v1-example

Is my assumption correct? 😅 Just thought it might help in your case.

[vinclou]

That pretty much resolves the issue yes, I do prefer things like this to be collocated for more granular(instead of global) control over it, so that it's easy to change and edit without jumping files. I see the pattern now, thank you so much.