Architecture/Design proposal for next-js migration

[AnshumanMahato]

This proposal is about #1499 #1500 #1501. I am here to share my ideas regarding segregating components into client-side and server-side.

If we are going by the App Router method, this is not much of an issue. Unlike Pages router, where we had to decide this, App Router handles this automatically. It all depends on the use of hooks and the nature of data requests.

From my analysis, most application components will be statically generated. Dynamic rendering will be used in components that render "plays", i.e., The "Trending Plays" section on the homepage, the "Plays" page, the "Leaderboard" page and a few other components.

Here are the details.

Trending Plays Component

From what I see, this section fetches the top 4 plays by likes. There is no user interaction so this section will use Server Side Rendering. The top 4 Plays will be requested on the server and rendered accordingly. For a better user experience, we can use Streaming to render an initial loading skeleton.

Plays Page

The Base layout, i.e., the header and footer will be statically generated. Two factors are to be considered for the rendering strategy of "Play" cards.

• Pagination
• Sorting feature

Here are some possible implementations for this.

1. We keep this entirely client-side. The implementation will be exactly as it is now for the most part. We may add pagination to make it better. All it would require is an additional state to store the page number. Sorting will be as it is.

2. We make the initial rendering server-side and then use client-side rendering for subsequent requests(due to sorting and page changes).

3. We keep the rendering of cards completely server-side. We can pass the sorting and the page requests as query parameters. Our URL will be something like this: "https://reactplay.io/plays?sort=like&order=desc&page=2". The only client-side components here will be the sorting and the pagination controllers. The functional design for both of them will be similar. Both will have a state variable and an effect to be executed whenever the state changes. In the effect function, we use the router from the "useRouter" hook to manipulate the query.

Leaderboard and Testimonial section

They will be server-side rendered.

Contributors Section

I am assuming that this section only lists the collaborators and the maintainers. If that's the case, this will be statically generated.

Individual Plays

The Header will be statically generated and the play will be client-side rendered. Client-side rendering would ensure that the plays do not require any major changes for migration.

I am available to answer any questions you may have. I look forward to your reviews and feedback.

[github-actions]

Hey! contributor, thank you for opening an Issue 🎉.

@reactplay/maintainers will review your submission soon and give you helpful feedback. If you're interested in continuing your contributions to open source and want to be a part of a welcoming and fantastic community, we invite you to join our ReactPlay Discord Community.
Show your support by starring ⭐ this repository. Thank you and we appreciate your contribution to open source!
Stale Marking : After 30 days of inactivity this issue/PR will be marked as stale issue/PR and it will be closed and locked in 7 days if no further activity occurs.

[priyankarpal]

yes, that sounds good 🚀 we should start working on it @AnshumanMahato

[AnshumanMahato]

Hmm sure. We need to start with initialising NextJS in the designated branch. I suggest moving the existing source code to a "legacy" folder and initialising NextJS. After that, we set the base layout, i.e., the navbar, the footer and the routing. Once this is done, we send out issues for different home page sections. Once done, we move to other pages.

[priyankarpal]

Hmm sure. We need to start with initialising NextJS in the designated branch. I suggest moving the existing source code to a "legacy" folder and initialising NextJS. After that, we set the base layout, i.e., the navbar, the footer and the routing. Once this is done, we send out issues for different home page sections. Once done, we move to other pages.

for Next.js migrations we already created the nextjs-migration branch

what do you think? @AnshumanMahato issue: #1497

[AnshumanMahato]

@priyankarpal Yeah I saw that. I am speaking about the initialization of work in that branch. It currently has the existing source code. I am saying we move all of that to a "legacy" directory and then set up NextJS project in the root. As suggested in #1497, the main branch stays untouched until the migration is complete.
Having the old source code available will help when we need to refer/copy something and we won't need to switch branches.

[priyankarpal]

@priyankarpal Yeah I saw that. I am speaking about the initialization of work in that branch. It currently has the existing source code. I am saying we move all of that to a "legacy" directory and then set up NextJS project in the root. As suggested in #1497, the main branch stays untouched until the migration is complete. Having the old source code available will help when we need to refer/copy something and we won't need to switch branches.

yes, sure

[github-actions]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[github-actions]

There hasn't been any activity on this issue recently, and in order to prioritize active issues, it will be marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a 👍 Because this issue is marked as stale, it will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!