Interested in contributing to A Few Games? There are a few ways to do so and this document runs down the basics of workflow & application structure.
Please note that this project has a code of conduct that is required of all participants (maintainer(s) included). All contributions will be licensed under the MIT License.
As mentioned in the README, filing an issue is a great start if you just want to put something in front of maintainers or ask questions before starting a pull request (PR).
A Few Games is a website with Tina CMS integration.
Core tech stack includes:
nextas the backbone of the app- By extension, the app uses
reactfor UI.
- By extension, the app uses
tailwindcssanddaisyuifor stylestinacmsto manage content, both static and dynamichusky&lint-staged(commit linting & pre-commit hooks)eslintandprettier(style and formatting)
Tina CMS has many benefits in the architecture and multiple static content blocks use it (home & about page, contribute/submission form).
When using Tina, the queries must happen server-side to benefit with caching at runtime. Never use a client query on a client component, as it will cause massive delay for contentful paint.
Basic scripts are used to run the app, all thanks to Next JS.
dev- local developmentbuild- build the app for production, locallystart- to run the production app after runningbuildlint- lints the app for JS, CSS andtailwind/daisyuistyles class name order
Finally, all commits run through husky and lint-staged for formatting. Errors must be fixed before re-committing.
- Fork the repo and create a branch from
main. - Commits are expected to follow a conventional commit pattern.
- Concise & regular commits help with code review and are encouraged.
- Open the pull request with a brief explanation of the issue & its proposed fix.
- All PRs need to pass CI checks before merging.
- A maintainer will merge the PR when if it is approved & ready.
All blog posts are managed via Tina CMS. They can be written in the CMS, or locally via markdown. Using the CMS provides a more user-friendly experience, at the expense of not having a draft feature (yet, but maybe one day it will be free!).
For drafts, create a local branch and use markdown, then create a PR
Since essays are managed via Tina, that means their content and the index page are provided at request time, but cached using Netlify CDN.
Blogs are accessed via their index page, which has cursor pagination.
The initial list of essays is always server rendered. When paginating, Tina client is queried, which can take a second or two (depending on internet connection) to resolve. While not ideal, this is their recommended method of paginating in the browser.
Recent posts are flagged with a "new" badge if they were published in the last 30 days.
While the database is similar to the blog and its content is leveraging Tina CMS, it is entirely composed of JSON, and is queried using an edge function (rather than a Tina query).
The primary reason to manage the "database" this way is to keep it open and referencable by everyone, not just on the website. In the future, it will most likely migrate to a proper database via SQL. For now, it's an MVP that works and the queries are fast.
Since the data is API-driven, it has no initial load state unless the page loads with url params. In this case, the edge function is called immediately.