loopbackio / loopbackio/loopback-next
Sugar API for defining URL redirects
- Dominant language
- TypeScript
- Stars
- 5.1k
- Forks
- 1.1k
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 27
Description
_This is a follow-up for https://github.com/strongloop/loopback-next/pull/2014._
When using LB4+ to serve HTML pages, it's useful to add a trailing slash to the URL when serving a folder, for example redirect `/explorer` to `/explorer/`. Without this redirect, relative URLs to assets like CSS & JS files are incorrectly resolved. For example, when served from `/explorer`, relative links like `./swagger-ui.css` are resolved in the parent directory, e.g. `/swagger-ui.css` instead of `/explorer/swagger-ui.css`.
Right now, a redirect can be implemented using a controller route that's hidden from the documentation and uses HTTP `response` object to send back the redirect. Such solution requires a lot of code and feels a bit hacky.
Let's make redirects a first-class feature in LB4 and provide a high-level API that's easy to use.
For example:
```ts
restApp.redirect('/explorer', '/explorer/');
restServer.redirect('/explorer', '/explorer/');
```
Under the hood, this can be implemented as a new Route class, for example:
```ts
app.route(new RedirectRoute('/explorer', '/explorer/'));
```
A mock-up implementation of RedirectRoute:
```ts
export class RedirectRoute implements RouteEntry, ResolvedRoute {
// ResolvedRoute API
readonly pathParams: PathParameterValues = [];
readonly schemas: SchemasObject = {};
// RouteEntry implementation
readonly verb: string = 'get';
readonly get path(): string { return this.sourcePath; }
// ...
constructor(
public readonly sourcePath: string,
public readonly targetPath: string,
public statusCode: number = 303,
) {
this.path = sourcePath;
}
async invokeHandler(
{response}: RequestContext,
args: OperationArgs,
): Promise {
response.redirect(this.statusCode, this.targetPath);
}
// ...
}
```
## Acceptance criteria
https://github.com/strongloop/loopback-next/pull/2512
- [x] The implementation, including unit/integration/acceptance tests
- Most of the tests should be written for `RestServer`.
- Add one or few tests for `RestApplication` at integration or acceptance level, just to ensure the new RestApplication API is covered.
- [x] Documentation
**TODO**
- [ ] Redirect to dynamically computed location (see the discussion below)
- [ ] Search for all places calling `.redirect(` and consider updating them to use the new route and/or the new RestServer/RestApplication sugar APIs. E.g. REST API Explorer.
- Redirect to externally hosted swagger-ui
- Redirect from `/explorer` to `/explorer/`
- [ ] Redirect to a location that's full URL (`http://example.com`) instead of a local path (`/home`). The trick is to skip appending `basePath`.
- [ ] Honor [`req.baseUrl`](https://expressjs.com/en/4x/api.html#req.baseUrl) when the LB4 app is mounted on an external Express application.
Contributor guide
Research direction
Start by reviewing the referenced pull request 2512 and the RestServer and RestApplication APIs described in the issue. Check the unit, integration, and acceptance tests for redirect behavior, then compare the remaining TODOs with the documented implementation to determine whether any work is still open.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100