-
-
Notifications
You must be signed in to change notification settings - Fork 843
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
Architecture/Design proposal for next-js migration #1502
Comments
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.
|
yes, that sounds good 🚀 we should start working on it @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. |
for what do you think? @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. |
yes, sure |
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! |
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! |
@AnshumanMahato hey bud, did you start working on this project? I'd love to catch-up with you to discuss how can we build this. I had been a contributor to React Play before but was away for some personal reasons. I want to start contributing again. |
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! |
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.
Here are some possible implementations for this.
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.
We make the initial rendering server-side and then use client-side rendering for subsequent requests(due to sorting and page changes).
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.
The text was updated successfully, but these errors were encountered: