mirror of
https://github.com/coder/coder.git
synced 2026-06-05 22:18:20 +00:00
78bf4c6d21
An issue came up last week... our `embed.go` strategy doesn't handle dynamic NextJS-style routes! This is a blocker, because I'm aiming to set up CD on Monday, and the v2 UI makes heavy use of dynamic routing. As a potential solution, this implements a go pkg `nextrouter` that serves `html` files, but respecting the dynamic routing behavior of NextJS: - Files that have square brackets - ie `[providers]` provide a single-level dynamic route - Files that have `[[...` prefix - ie `[[...any]]` - are catch-all routes. - Files should be preferred over folders (ie, `providers.html` is preferred over `/providers`) - Fixes the trailing-slash bug we hit in the previous `embed` strategy This also integrates with `slog.Logger` for tracing, and handles injecting template parameters - a feature we need in v1 and v2 to be able to inject stuff like CSRF tokens. This implements testing by using an in-memory file-system, so that we can exercise all of these cases. In addition, this adjust V2's `embed.go` strategy to use `nextrouter`, which simplifies that file considerably. I'm tempted to factor out the `secureheaders` logic into a separate package, too. If this works OK, it could be used for V1 too (although that scenario is more complex due to our hybrid-routing strategy). Based on our FE variety meeting, there's always a chance we could move away from NextJS in v1 - if that's the case, this router will still work and be more tested than our previous strategy (it just won't make use of dynamic routing). So I figured this was worth doing to make sure we can make forward progress in V2.