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.
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.
since chain names are known statically, I wonder if its helpful to use getStaticPaths on these routes?
There was a problem hiding this comment.
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.
…o kumpis/fixes-cleanups
Interacttab