manual-pink•12mo ago

How to Handle Routes for Resources that are Related

I have organizations that have many deployments and users, and deployments have many devices How sould I structure my resources routes in the <Refine> component under the resources property to handle this? Should I do something like for uses:

{
  name: "users",
  list: "/organizations/users",
  create: "/organizations/users/create",
  edit: "/organizations/users/edit/:id",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

{
  name: "users",
  list: "/organizations/users",
  create: "/organizations/users/create",
  edit: "/organizations/users/edit/:id",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

or should I do:

{
  name: "users",
  list: "/organizations/:id/users",
  create: "/organizations/:id/users/create",
  edit: "/organizations/:id/users/edit/:id",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

{
  name: "users",
  list: "/organizations/:id/users",
  create: "/organizations/:id/users/create",
  edit: "/organizations/:id/users/edit/:id",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

Can i use the same :id notifier, or does it need to be different if its used multiple times within the same route?

4 Replies

kapa.ai•12mo ago

Hi @nick_montoya. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- In refine, you can structure your resources routes in the <Refine> component under the resources property to handle complex relationships like organizations having many deployments and users, and deployments having many devices. You can define your actions (list, create, edit, show, clone) as paths instead of components. This will allow you to define custom routes for actions and take advantage of the full potential of your router without being restricted to the routes created automatically. For your case, the second option you provided seems more appropriate as it allows you to specify the organization id in the route:

{
  name: "users",
  list: "/organizations/:id/users",
  create: "/organizations/:id/users/create",
  edit: "/organizations/:id/users/edit/:userId",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

{
  name: "users",
  list: "/organizations/:id/users",
  create: "/organizations/:id/users/create",
  edit: "/organizations/:id/users/edit/:userId",
  meta: {
    label: "Users",
    icon: <GroupIcon />,
    canDelete: true,
  },
},

Note that I've changed the :id in the edit route to :userId. This is because in a route, each :id is a placeholder for a specific value. If you use :id twice in the same route, it might cause confusion or unexpected behavior. It's better to use different identifiers for different parts of the route. Remember that these paths are just examples, and you can customize them to fit your application's needs. The new enterprise-grade routing structure in refine v4 allows for effortless handling of complex structures like this. For more information, you can refer to the refine v4 announcement blog post (https://refine.dev/blog/refine-v4-announcement) and the refine documentation (https://refine.dev/docs/tutorial/understanding-resources/index/). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•12mo ago

<@263527875506995202> kapa.ai is still learning and improving, please let us know how it did by reacting below

eastern-cyan•12mo ago

Bot is right about the duplicate :id definition which is probably going to cause some unexpected behaviors. But I think the suggested route definition is wrong. refine expects the id parameter from the router to be related with the active resource. In this case when the resource is users instead of having the organization id represented with the :id, defining the userId as id is better and will make refine work without setting the id explicitly. I suggest something like /organizations/:organizationId/users/edit/:id which is more convenient. But still, the route definitions are completely up to you, you can go with anything you want 🤣

manual-pink•12mo ago

Yea I noticed that too lol, I figured it would be best to have id relevant to the resource