Significant-Gravitas
[Builder] Implementation of Error and Loading boundaries NextJS
Duplicates
- [X] I have searched the existing issues
Summary 💡
We should implement NextJS 14's built-in loading.tsx and error.tsx file naming conventions throughout our project. This would replace the current standard React approach to loading states and error handling.
The feature should work as follows:
- Identify all routes in our NextJS 14 app that require loading states or error handling.
- For each identified route, create corresponding loading.tsx and error.tsx files.
- Move existing loading logic into the loading.tsx files.
- Move existing error handling logic into the error.tsx files.
- Remove any manual implementations of Suspense boundaries related to loading states.
- Remove any custom error pages that Next.js can handle by default.
Examples 🌈
NextJS documentation provides excellent examples of how these conventions work:
Loading UI: https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming Error Handling: https://nextjs.org/docs/app/building-your-application/routing/error-handling
Motivation 🔦
What is the motivation behind the feature ask?
Currently, our developers are not utilizing NextJS 14's loading.tsx and error.tsx conventions. Instead, they're implementing loading states and error handling using standard React methods.
This approach has several drawbacks:
- It requires manual implementation of Suspense boundaries for loading states.
- Custom error pages need to be created, which NextJS can handle automatically.
- It doesn't take full advantage of NextJS 14's App Router features.
- It leads to inconsistent implementation across different parts of the application.
By adopting NextJS 14's conventions, we can:
- Simplify our codebase by leveraging built-in NextJS features.
- Improve consistency across the application.
- Reduce the amount of boilerplate code developers need to write.
- Make our application more maintainable and easier to understand for new developers.
- Potentially improve performance by using NextJS's optimized loading and error handling.
@Swiftyos If you don't mind I would like to implement this in our Application. This will help with maintaining a clean codebase that reflects to the standard practices of NextJS 14's App Router.
@Swiftyos If you don't mind I would like to implement this in our Application. This will help with maintaining a clean codebase that reflects to the standard practices of NextJS 14's App Router.
Yeah that would be fantastic
@Swiftyos Feel free to checkout the PR I've linked above.
One callout here would be that to see better UX for our users it would be ideal for use to leverage more server side components and less client side components. This would require a larger refactor consideration and is not part of this changes at the moment.