You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our team uses page.js for routing in a SPA we maintain. A debate recently came up as we tried to figure out the best way to add a handler that ran after every page load for our app.
One idea that came up was the idea of having a '*' route handler that ran before all other routes and ran some functionality after the next() call.
This solution worked well for us because it allowed us to execute some functionality before specific route handler logic and other functionality afterwards without having to create multiple '*' route handlers.
However, a teammate noticed that none of page.js's documented examples ran logic in a function after a next() call and feared that what we had come up with was a hack.
So my question is essentially: is running logic after a next() call in a handler an acceptable way to specify an order for routing behavior?
Is it a reasonable assumption that logic after a next() call would always run only when other route handlers have executed or is coding in this way depending too much on implementation details of how page.js runs route handlers? ie: if it's possible that page.js could one day change its implementation to use async code in next().
(In our app, we originally started with a '*' route handler that was registered after all other routes, but we wanted to move away from this because it made next() handling complex for our use case.)
The text was updated successfully, but these errors were encountered:
Hello!
Our team uses page.js for routing in a SPA we maintain. A debate recently came up as we tried to figure out the best way to add a handler that ran after every page load for our app.
One idea that came up was the idea of having a '*' route handler that ran before all other routes and ran some functionality after the next() call.
ie:
This solution worked well for us because it allowed us to execute some functionality before specific route handler logic and other functionality afterwards without having to create multiple '*' route handlers.
However, a teammate noticed that none of page.js's documented examples ran logic in a function after a next() call and feared that what we had come up with was a hack.
So my question is essentially: is running logic after a next() call in a handler an acceptable way to specify an order for routing behavior?
Is it a reasonable assumption that logic after a next() call would always run only when other route handlers have executed or is coding in this way depending too much on implementation details of how page.js runs route handlers? ie: if it's possible that page.js could one day change its implementation to use async code in next().
(In our app, we originally started with a '*' route handler that was registered after all other routes, but we wanted to move away from this because it made next() handling complex for our use case.)
The text was updated successfully, but these errors were encountered: