- commit
- 45e804f
- parent
- 917725c
- author
- Eric Bower
- date
- 2024-02-16 18:43:19 +0000 UTC
docs: copy
1 files changed,
+25,
-0
+25,
-0
1@@ -97,6 +97,31 @@ const fetchUsers = api.get<never, Success>(
2 );
3 ```
4
5+# Using variables inside the API endpoint
6+
7+Just like other popular server-side routing libraries, we have a way to provide
8+slots in our URI to fill with actual values. This is critical for CRUD
9+operations that have ids inside the URI.
10+
11+```ts
12+const fetchUsersByAccount = api.get<{ id: string }>("/accounts/:id/users");
13+const fetchServices = api.get<{ accountId: string; appId: string }>(
14+ "/accounts/:accountId/apps/:appId/services",
15+);
16+```
17+
18+One ergonomic feature we baked into this functionality is: what happens when
19+`id` is empty?
20+
21+```ts
22+const fetchUsersByAccount = api.get<{ id: string }>("/accounts/:id/users");
23+store.dispatch(fetchUsersByAccount({ id: "" }));
24+```
25+
26+In this case we detect that there is no id and bail early. So you can hit this
27+endpoint with empty data and it'll just exit early. Convenient when the view
28+just throws around data without checking if it is filled.
29+
30 # The same API endpoints but different logic
31
32 It is very common to have the same endpoint with different business logic