feat(site): Generate static website

[HamidMolareza]

When there are many problems and solutions, we need to use the browser search to find the desired solution. It would be great if there were a search section on the page itself.

If the site is static, it can be hosted on a CDN or GitHub to be fast and free.

---

Requirements:

• Should be static. All searches and filters must be client-side.
• A search field that searches across all table columns (query ID, question title, solution language, even contributor names).
• A filter to limit the search to a specific programming language (e.g., Python solutions only).
• SEO
• It would be great if it has an attractive design and includes explanations about the project and how to contribute.

---

We probably have two options:

1. Using a static template that the program can populate with data.
2. Using a static site generator library/framework like Next.js, which can take data (e.g., from JSON) and generate the static site.

[HamidMolareza]

@ARiYaNSEp0-0

As a front-end developer, you might be interested in working on such an idea.

This is an initial idea. It needs to be evaluated to see if it's worthwhile.

[ARiYaNSEp0-0]

I'm very interested to be part of this idea. actually It's one of my problem too when I want to add new solution I should search with browser or sometimes folder name in terminal. thank you for considering me

[HamidMolareza]

I meant turning this page into a static website with a search feature, relevant to the current repository. Of course, later on, all solutions could also be collected.

If you have any suggestions, please share them.

[ARiYaNSEp0-0]

I have a question about handling the data of this site. I would be grateful if you could answer it. In general, in my previous experiences, there was an API where, for example, I used to get a list from the backend, and request was sent either on the initial page load or based on a specific event.

I am also familiar with other modes, for example, when there is a JSON file that contains all The data is included and it can be IMPORTED in another file and used, but now in the case you mentioned about Next JS, if the data changes every time, the project must be BUILD again from the beginning so that those static files have that data and this The fact that questions are being added one after another does not cause a problem.

Edit: my whole point and question if there is an JSON file on site repo how this file get updated when in the main QUERA repo solutions added or edited or ...

[HamidMolareza]

We already have the data generation program (the current project), and with a simple modification, it can output the data in various formats (like JSON or HTML tables). The question to determine is the approach our front end will use.

If we go with the first approach, it’s exactly like what we do with markdown files. We create a blank template and leave the table area empty. The program generates the data as an HTML table and replaces it in the main template. This approach would be more suitable if we’re not using a library or framework like Next.js.

However, if we use the second method (with a library or framework like Next.js), the best approach for transferring data would likely be via a JSON file.

• A PR is merged with the master branch.
• A GitHub Action is triggered to run the readme-generator program, which generates the JSON file.
• Next, the build command for the library or framework is called to recreate the static site using the JSON file.
• Finally, the site files are committed to ensure they persist.

Which approach do you prefer?
Using a library or framework like Next.js, or a raw approach?
Whatever method you choose, I will take care of the rest.

[ARiYaNSEp0-0]

Thank you for your detailed response. I think the first approach is more manual and hard to maintain. I feel that way because, in the long run, we might have 1,000 or 2,000 solutions. Each time a commit happens and a solution is appended to the HTML table (or the whole solutions), the HTML file size increases. This could affect the initial loading time for users and potentially hurt SEO.

And I think second approach also will have same problem this time we have JSON and static site generation again it's just generating html files and a table full of solutions and other details could increase in time.

But I prefer using a framework/library in general until requirements are handled

[ARiYaNSEp0-0]

I have an idea. What about implementing both approaches to handle the basic requirements, and then discussing and analyzing the pros and cons of each approach?

[HamidMolareza]

I think the second solution is better. Though not necessarily Next.js—perhaps a lighter library or framework would be more suitable.

If we don’t want to spend too much time evaluating options, I think Next.js will be fine.

[ARiYaNSEp0-0]

Very good. I am ok with Next JS too, so what is our first step I mean repo creation and stuff related to git and git hub?

[HamidMolareza]

We can create a separate repository, dockerize the project, and upload it to hub.docker.com.
This way, in the main repository, we can first call the data generation program and then run the frontend program to create the website in a specific folder and use GitHub Pages.

I can create this new repository, or you can—it doesn’t matter to me.
In any case, you can work on the frontend code, and I’ll handle the rest.

So, what should we do? Will you create the repository, or should I?

[ARiYaNSEp0-0]

I can create the repo for frontend but for contributing related (guides, license, etc) for repo you have more experience than me

[HamidMolareza]

I created the project and sent the collaboration request.
I have done the initial and general setup, and I will complete the rest of the configurations related to the code once you submit the initial codes, such as dockerizing the project, etc.

The project structure:

├── CODEOWNERS
├── docs
│   ├── CODE_OF_CONDUCT.md
│   ├── CONTRIBUTING.md
│   └── SECURITY.md
├── LICENSE
├── package.json # For pre-commit (local development)
├── package-lock.json
├── README.md
├── scripts
│   └── setup-hooks.sh # Config local development like pre-commit and git hooks
└── src
    └── nextjs-codes # Put codes in this folder: package.json, eslint, tsconfigs, etc

The main branch is protected and can only be merged through a PR.
I suggest keeping the changes in the dev branch before release, and then creating a PR for main for the release.

After the merge, the release action and the changelog generation should be triggered.
The changelog file will be automatically generated by the release-please action, which works based on Conventional Commits. So, I recommend using this method.

[ARiYaNSEp0-0]

Thank you. I have learned many things from open source and GitHub through you. Regarding Docker, I don't have much experience with it, but I want to learn. You mentioned Dockerizing, so I searched for nextjs, and some guides popped up in the results. Are they enough for Dockerizing or this template have other steps?

[HamidMolareza]

Dockerizing this project is a bit different.

In frontend projects, we usually build the project, package the output with nginx configuration, and create the image. However, this project is not a site; it's a site-generator. This means every time the Docker container runs, the project needs to be built from scratch, which changes the approach slightly. But this difference doesn't necessarily mean it's harder.

In this method, the source code should be included in the container to allow rebuilding every time.

I haven’t given this much thought yet and plan to do some research later to ensure this is the best approach. For instance, maybe Next.js has tools I'm unaware of. But for now, I think this method makes the most sense.

[ARiYaNSEp0-0]

Correct, actually I don't if it helps or not but nextjs have a template for docker https://github.com/vercel/next.js/tree/canary/examples/with-docker

[HamidMolareza]

Please feel free to openly share any thoughts or suggestions in the Issues section of the project.

I consider this project more for you than for myself since I’m not a frontend developer and don’t intend to deeply into this field.

I haven’t set up the project’s code structure to give you the freedom to create it however you like, even if it’s not necessarily based on best practices. (For example, I prefer typescript but you can use javascrpt)

Discussing changes in the Issues section allows them to be visible to others, gathering feedback, and aligns with standard practices. It’s a good approach, but you can apply any changes you find appropriate.

I’ll also try to follow this project’s issues and prioritize them accordingly.

[HamidMolareza]

In non-organizational GitHub repositories, the settings are more limited, and it seems I can’t add someone as a maintainer.

Because of this, I’m not sure if you have merge access for pull requests or not.

If you have access, feel free to merge pull requests whenever you think it’s appropriate.

If you’d like my opinion on a pull request, you can add me to the code review section of the pull request so I’ll get a notification about it.

[HamidMolareza]

Correct, actually I don't if it helps or not but nextjs have a template for docker https://github.com/vercel/next.js/tree/canary/examples/with-docker

The Docker file for this project is not suitable for our needs because it uses Next.js as a server, which we don’t require for a simple project like this.