One route or multiple routes for a quiz?
Answered
African Slender-snouted Crocodil… posted this in #help-forum
African Slender-snouted CrocodileOP
Hi,
I'm building a wizard-like quiz in a next js 14 app using app router.
The quiz has 10 questions.
I'm planning on using my own context for persisting form data during full page refreshes. The form data will be stored in localStorage.
And react-hook-form for handling my form.
What I am unsure about is whether I should have ONE route for the entire quiz; i.e. /quiz OR MULTIPLE routes; e.g. /quiz/question-1, /quiz/question-2 etc.
And the second thing I'm not quite sure how to solve is how to implement the NEXT and PREVIOUS button user actions using next js 14 app router APIs/architecture.
All these pieces should play nicely together.
Any thoughts or suggestions or maybe some code snippets or links would be much appreciated?
I'm building a wizard-like quiz in a next js 14 app using app router.
The quiz has 10 questions.
I'm planning on using my own context for persisting form data during full page refreshes. The form data will be stored in localStorage.
And react-hook-form for handling my form.
What I am unsure about is whether I should have ONE route for the entire quiz; i.e. /quiz OR MULTIPLE routes; e.g. /quiz/question-1, /quiz/question-2 etc.
And the second thing I'm not quite sure how to solve is how to implement the NEXT and PREVIOUS button user actions using next js 14 app router APIs/architecture.
All these pieces should play nicely together.
Any thoughts or suggestions or maybe some code snippets or links would be much appreciated?
Answered by B33fb0n3
yes, I like to use the KISS principle. KISS = Keep it simple studip. So why to handle mutiple routes, server actions, serverside rendering and all the stuff around it, when it can be so easy
8 Replies
African Slender-snouted CrocodileOP
@B33fb0n3 thanks. Do you have any why's or pros and cons you could share?
@African Slender-snouted Crocodile <@301376057326567425> thanks. Do you have any why's or pros and cons you could share?
yes, I like to use the KISS principle. KISS = Keep it simple studip. So why to handle mutiple routes, server actions, serverside rendering and all the stuff around it, when it can be so easy
Answer
@B33fb0n3 yes, I like to use the KISS principle. KISS = *Keep it simple studip*. So why to handle mutiple routes, server actions, serverside rendering and all the stuff around it, when it can be so easy
Just to validate this a bit more:
If you're concerned about state management and using localStorage, you're already leaning towards a client-side app, at least until the form is submitted. Using a client component to add steps is more straightforward and keeps things simple.
The only remaining question is whether to show the step in the URL or infer the step using data from localStorage. Inferring the step is more advanced and fun to build, but showing it in the URL is more user-friendly and expected.
You could even do both: infer the step and update the URL accordingly. This way, users won't be confused by seeing just
If you're concerned about state management and using localStorage, you're already leaning towards a client-side app, at least until the form is submitted. Using a client component to add steps is more straightforward and keeps things simple.
The only remaining question is whether to show the step in the URL or infer the step using data from localStorage. Inferring the step is more advanced and fun to build, but showing it in the URL is more user-friendly and expected.
You could even do both: infer the step and update the URL accordingly. This way, users won't be confused by seeing just
/quiz with no indication of the step they're on in the browser history.@Luke Just to validate this a bit more:
If you're concerned about state management and using localStorage, you're already leaning towards a client-side app, at least until the form is submitted. Using a client component to add steps is more straightforward and keeps things simple.
The only remaining question is whether to show the step in the URL or infer the step using data from localStorage. Inferring the step is more advanced and fun to build, but showing it in the URL is more user-friendly and expected.
You could even do both: infer the step and update the URL accordingly. This way, users won't be confused by seeing just `/quiz` with no indication of the step they're on in the browser history.
I am not OP, but if you ask me, of course you can set the current step to use url. Just replace
const [step, setStep] = useState(0) to const [step, setStep] = useQueryState("step")African Slender-snouted CrocodileOP
@Luke I went with /quiz /quiz/step-1 /quiz/step-2 etc. I've tested this and it works fine. Very user friendly also like you pointed out.
@B33fb0n3 I'm using Next.js 14's built-in features
@B33fb0n3 I'm using Next.js 14's built-in features
<Link>and useRouter() instead of having the steps in state - I find this to be much more intuitive when developing (better DX).Of course you can do this too and of course it works as well. I like to use states instead of routes, because it’s way easier. Not only to create, but also easier to maintain. You might want to read your about the „KISS“ principle
@African Slender-snouted Crocodile
@African Slender-snouted Crocodile
@African Slender-snouted Crocodile <@1070665442298966106> I went with /quiz /quiz/step-1 /quiz/step-2 etc. I've tested this and it works fine. Very user friendly also like you pointed out.
<@301376057326567425> I'm using Next.js 14's built-in features `<Link>`and `useRouter()` instead of having the steps in state - I find this to be much more intuitive when developing (better DX).
Yup, nothing wrong with this approach. Not how I'd build it but whatever works, works 🎉