https://joookiwi.github.io/smm-encyclopedia

• List of elements to do
• Development for the web application
  • Standard used in the project
    • Imports
    • Visibility
    • Folder structure
    • File naming
    • Variable / methods / class naming
    • Files using a CSV source
    • Dependencies
    • Routes
  • NPM commands
    • Prerequisites
    • Run the project locally (desktop and mobile)
    • Running tests
    • Running testing tools
    • Deploying the changes to the server

A simple project made to retrieve most (if not every) information in all 3 Super Mario Maker games. It contains:

• Super Mario Maker (WiiU)
• Super Mario Maker for Nintendo 3DS (3DS)
• Super Mario Maker 2 (Switch)

The information is mostly based on the SMM2 game.

This project is intended to be a simple project to help on research.
It is also there give the details as simple as they can get.
More is to add once this huge project is finished.

The languages supported by the project are the ones available in the games:

• English (american & european)
• French (canadian & european)
• German
• Spanish (american & european)
• Italian
• Dutch
• Portuguese (american & european)
• Russian
• Japanese
• Chinese (traditional & simplified)
• Korean

The other languages seen in the project can include Hebrew, Polish, Ukrainian & Greek. Although, they are only there for some names.

• When giving an url example.com/path, it would be based on the browser language.
  And for example.com/en-US/path, then the language would be set to American English.
• Font family
  • from the Super Mario Maker games
  • from SMB, SMB3, SMW, NSMBU & SM3DW specifically
• Colour mode implementation (independent of each and another)
  • Dark mode
  • Colour-blind mode
• Search engine.
• Options that would change the URL based on the application loaded.
• Sub-pages with reactive URL.
• Secret pages
  • by URL
  • by key combination
  • maybe other ways to create them

In order to have a clean way to navigate to the project, multiple standards have been made.

They are separated in different sections

• Import ordering
  1. SCSS files (for React components)
  2. Dependencies import
  3. Type import (not useful to debug)
  4. Real import (if used at compile time → import type)
• Spacing for the import is aligned for better readability
• Ordered alphabetically by group

Since some visibilities are present in other languages (like Kotlin, Java, PHP or C#), the project utilizes some standard on the visibilities.

It utilizes the Typescript system for the pre-established visibilities. Then, for those that are not in the system, it uses somme pattern for it.

 public anExample
public anExample()

anExample
anExample()

protected _anExample
protected _anExample()

#anExample
#anExample()
private __anExample
private __anExample()

Folder structures the files. Most of them are self-explanatory.

The names of the files are important since some of them are for Typescript and others give meaning to them.

The variables, methods & classes use a different format, but they all share at some point the standard.
They don't follow directly the standard, but have a general format followed.

AN_EXAMPLE

anExample

AnExample

anExample_withSomething_secret

#anExample
#anExample()

$1Example
$1Example()

_anExample()

get __anExample() {
  this.#anExample
}
set __anExample(value) {
  this.#anExample = value
}

protected _anExample() {
    return somethingToBeCalledOnce
}
protected _anotherExample(a, b, …,) {
    return somethingToBeCalledOnceWith(a, b, …,)
}

[a, b, c,]
{a: 1, b: 2, c: 3,}
anExample(a, b, c,)
new AnExample(a, b, c,)

class AnExample<T,>{ ... }
anExample<T,>(t: T,)

type AnExample = | TypeA | TypeB

type AnExampleString = 'something'
type AnExampleCharacter = 'A'

const anExample = 420 / 69

class AnExample {
  fieldA
  fieldB
}

interface AnExample {
  fieldA
  fieldB
}

type AnExample = `Jank ${| 'city' | 'game'}`

const anExampleNumber = 123_456
const anotherExampleNumber = 1_042_069

type AnExample = | AType | null

In the core (src/core/...), the files have some formatting that each have their responsibility. The only ones that are used outside are:

• Interface
• Enum (sometimes even in the src/util/DynamicImporter.ts)
• The loader types (Loader.types)

The rest should not be used outside the same package (folder).

Every dependency are described bellow with the direct dependency and the indirect (via the DynamicImporter utility class)

Every route in the project has a reason to exist. It can either be to have a default value or to be accessible by the URL directly.

So far, the paths are separated by multiple parts:

1. The optional language (en-AM, en-EU, fr-CA, fr-EU, de, es-AM, es-EU, it, nl, pt-AM, pt-EU, ru, ja, zh-tw, zh-cn or ko)
2. The game (game- + 1, 3ds and/or 2) with its default game-2
3. The display option (list, card or table)
4. The ending paths:

Before running the application, make sure that npm is installed.

Then, from there,

• run npm install to install the node_modules package

To run the project, the command npm run start is the only thing to do.

• Start the execution of the tools;
• Start the development mode;
• Reload on edits (and save);
• In the console (and command prompt), display any lint errors.

The project could also be run with npm run fast-start to omit:

• CSV → Json (resources/csv → src/resources/compiled)
• Copy images for CSS (public/* → src/resources/images)
• Copy the locales from resources/locale to the src/lang/locale
• (Other things in the future)

By default, it will open it in the default browser automatically. If it has not worked, then open localhost:3000/smm-encyclopedia to display the application.

If it needs to be tested on other devices than the local machine, there will be another address. An example could be 192.168.4.20:3000/smm-encyclopedia.

The tests are not part of the validations on the server. They are only done locally.

It has:

• Testing the CSV files npm run test-file
• Testing the entity types (upcoming tests)

The command to execute the test command tool is npm run test.

Then, from that, it will start an interactive watch mode. For more details, see how to run the tests.

Since the project uses the workflow (in .github/workflows/workflow.yml), it will automatically push the changes once there is a commit in the main branch.

It automatically calls the command npm run deploy (implicitly calling npm run predeploy).

With the deployment, it will automatically call npm run build and will:

• Minify of the files;
• Contain files formatted in static/js/[420.jank69].chunk.js and static/css/[420.jank69].chunk.css.

See the application's deployment to know in details how the React build is done.

The code will be pushed in the branch github-pages branch by the workflow.