-
Notifications
You must be signed in to change notification settings - Fork 196
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
fix(explorer): various fixes #3299
Conversation
🦋 Changeset detectedLatest commit: d9075cc The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
export default async function ChainPage({ params }: Props) { | ||
return redirect(`/${params.chainName}/worlds`); | ||
export default async function ChainPage({ params: { chainName } }: Props) { | ||
return redirect(`/${chainName}/worlds`); |
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.
thoughts on validating the chain name here and only redirect when valid?
this is what causes the /favicon.ico/worlds
404 error
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.
since chain names are known statically, I wonder if its helpful to use getStaticPaths
on these routes?
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.
getStaticPaths
only works with pages
router while we are using app
router which is the recommended way now and moving forward.
There is something similar in the app
router called generateStaticParams
which I think we can use the same way. However, I don't think we should make this page static given that the world addresses which we display in world entry page are dynamic.
Now getServerSideProps
inside app
router is essentially replaced with async
server-side component with a fetcher function inside. So based on that, the validation also is moved to the component itself. What I think would be best to do here is to actually move the validation inside layout.tsx
. I already did that for (explorer)/[chainName]/worlds/[worldAddress]/layout.tsx
but actually thinking that same could be done for (explorer)/[chainName]/layout.tsx
(which doesn't exist yet but could be created for the purpose of validation). This way there's less repeating logic at least.
Interact
tab