Nested routes with path parameter

[JUNIORCO]

We're in the process of migrating from express to this library. Here's an example of what we're moving:

router.get("/inventories", (req, res) => InventoryController.getInventories(...));

router.post("/inventories", (req, res) => InventoryController.createInventory(...));

router.get("/inventories/:id", (req, res) => InventoryController.getInventory(...));

router.put("/inventories/:id", (req, res) => InventoryController.updateInventory(...));

router.get("/inventories/filterOptions", (req, res) => InventoryController.getFilterOptions(...));

Our router using express-zod-api looks like:

const router: Routing = {
  api: {
    inventories: {
      '': new DependsOnMethod({
        get: Endpoints.getInventoriesEndpoint,
        post: Endpoints.createInventoryEndpoint,
      }),
      ':id': new DependsOnMethod({
        get: Endpoints.getInventoryEndpoint,
        put: Endpoints.updateInventoryEndpoint,
      }),
      filterOptions: Endpoints.getInventoryFilterOptionsEndpoint,
    }
  },
};

The issue we're running into is the /inventories/filterOptions route is not running the endpoint Endpoints.getInventoryFilterOptionsEndpoint, instead it's running Endpoints.getInventoryEndpoint and it thinks filterOptions is the id.

Not sure if we have to setup the routing in a different way to handle nested routes with path params, or if this is a bug.

[RobinTail]

Hello @JUNIORCO ,
Did you try to move filterOptions entry above the :id one?

[JUNIORCO]

@RobinTail Thank you that fixed it 🙌 Can I just ask why that works?

[RobinTail]

Sure, @JUNIORCO .

When starting your server, express-zod-api walks through your Routing and calls app.[method]( path, ... ) for each entry the similar way you did it before migration. It tells the express app how to process the requests to those paths. Due to the object-based nature of the Routing, it uses Object.keys() to iterate. Thus, the order of the setup is preserved.

.get("/inventories/filterOptions", ... );
.get("/inventories/:id", ... );

For your case the order does matter, because the entry :id is a placeholder for anything: any combination of alphanumeric symbols, including filterOptions. Thus, in your setup filterOptions is a very special kind of :id. 🙌🏽

Therefore, when requesting GET /inventories/filterOptions route, your express app actually has two matching handlers for it. So, express will try them in original order :)

More information here:
https://expressjs.com/en/guide/routing.html

[RobinTail]

@JUNIORCO , for your future refactoring you may consider making filterOptions a first level segment of a route, having filtering options for different entities on demand, like this:

/filterOptions/inventories
/filterOptions/users
/filterOptions/otherStuff

Kinda re-arrange it do a very own dedicated place. Thus, you'd not need to deal with collisions and order-depending Routing definitions.