-
Notifications
You must be signed in to change notification settings - Fork 929
feat: nextrouter pkg to handle nextjs routing rules #167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## main #167 +/- ##
==========================================
+ Coverage 64.66% 68.03% +3.37%
==========================================
Files 58 111 +53
Lines 648 6004 +5356
Branches 68 68
==========================================
+ Hits 419 4085 +3666
- Misses 217 1526 +1309
- Partials 12 393 +381
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunate but seems necessary.
Instead of this, could we do the following:
- Enable
trailingSlash
innext.config.js
so all files are namedindex.html
. - Manually specify parameterized routes. This sucks, but I'm nervous to add a few hundred lines of routing code (albeit tested) when we could add like:
router.Match("/projects/{organization}/{project}", serveStaticHandler)
Thoughts?
I thought about this after our discussion and FE variety yesterday - but I'm not a fan, because it seems too hard to maintain. The problem is our development environment with Another thing is - our previous routing code wasn't tested at all, so a lot of the previous routing code is removed and covered with tests. I added 225 lines of routing code - covered with tests - but removed 185 lines of code that wasn't tested at all. So it's really only net +40 lines of tested code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonderful tests! I went hard into nits for this, but overall this is wonderfully tested and structured code 🥳🥳🥳
nextrouter/nextrouter.go
Outdated
"cdr.dev/slog" | ||
) | ||
|
||
// Options for configuring a nextrouter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want this to be confused with our primary app routing logic.
For that reason, what do you think about this being in site
like it was before? It could even be at the root if you feel that's clean enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'd prefer to keep it in its own package so it's clear that it is stand-alone - how about I move it to site/nextrouter
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved in 19fcfac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me!
BTW I agree with your comment. It is a bit too sketchy. After reading through the code extensively my POV changed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An absolutely wonderful change!
Thanks for reviewing, @kylecarbs ! |
nextRouterHandler, err := nextrouter.Handler(filesystem, &nextrouter.Options{ | ||
Logger: logger, | ||
TemplateDataFunc: templateFunc, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: I really like that the nextjs stuff is isolated into a self-contained module.
@@ -0,0 +1,238 @@ | |||
package nextrouter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can you add a package-level comment about what this module is? It would need to go in nextrouter/doc.go
.
See here: https://github.com/coder/m/blob/master/product/coder/pkg/vm/ec2/doc.go
I'm happy to contribute this as my first coder/coder
PR if you're ok with that 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like doc.go
, but only if we can navigate this repo on https://go.dev. Otherwise it's generally gone unmaintained D:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that'd be great to contribute @vapurrmaid !
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 serveshtml
files, but respecting the dynamic routing behavior of NextJS:[providers]
provide a single-level dynamic route[[...
prefix - ie[[...any]]
- are catch-all routes.providers.html
is preferred over/providers
)embed
strategyThis 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 usenextrouter
, which simplifies that file considerably. I'm tempted to factor out thesecureheaders
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.