Next.js imposes one constraint: ISR only works with URL parameters like
/articles/<page>, not GET parameters like /articles?page=1.As of writing however, we don't use any ISR as it adds a lot of complication. But still, we are trying to stick to the general principle that if something might ever be ISR'ed in the future, then we would like to keep it as parameter rather then GET. It feels sane.
The only things that we are ever consider ISR'ing are the pre-rendered version of articles and issues, excluding any metadata of those that changes often or depends on logged in users.
All lists of things will never be ISR'ed, as those can change constantly. One conclusion of this is that:which appear only in lists of things, will always be part of the GET query, and not params.
- page number
- ordering
- other search-like parameters
Types:
- booleans are:
0for false1for true
- tristate booleans are:These are used for example when filtering booleans where the default is to show only either true or false but not both, e.g., we hide locked users by default, i.e.
0for false1for true2for all
locked=0is the default, therefore we have:The user list also hides users without verified email by default:- localhost:3000/go/users?locked=0: show only unlocked users. Same as the default localhost:3000/go/users.
- localhost:3000/go/users?locked=1: show only locked users.
- localhost:3000/go/users?locked=2: show both locked and unlocked users.
- localhost:3000/go/users?verified=1: show only users with verified email. Same as the default localhost:3000/go/users.
- localhost:3000/go/users?verified=0: show only users with unverified email.
- localhost:3000/go/users?verified=2: show users with both verified and unverified email.