# Setting Up
###### tags: `module-tutorial` `foundry-vtt`
There's a bit of up-front work we can do to make our lives easier going forward.
## I. Create a Class for our Module
There's some base logic and constants which we can define in a central location that will make our lives easier.
In our `todo-list.js` file, we should define a `ToDoList` class:
```js=
class ToDoList {
static ID = 'todo-list';
static FLAGS = {
TODOS: 'todos'
}
static TEMPLATES = {
TODOLIST: `modules/${this.ID}/templates/todo-list.hbs`
}
}
```
:::info
**Programming Concept: `static`**
You'll notice we're putting [`static`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/static) in front of each of these things. Classes have two kinds of properties: `static` and... not... static... Marking a property as `static` basically means that it can be accessed by functions outside the class where it is defined.
:::
### ID
There's a few places where `ID` will be useful in our module's code:
- Getting and Setting Flags
- Getting and Setting Settings
- Registering our Templates
:::info
**Programming Concept: Constant**
Generically, a [constant](https://developer.mozilla.org/en-US/docs/Glossary/Constant) is something which should never change. Our module's id is an example of this. It's convention to define these with all caps names.
:::
### FLAGS
This little object is where we define what flags our module is going to use when we try to get or set flags later while we're setting up our data layer.
Since we use this 'todos' string in several places, we're hoping that by defining it in this little object, we can avoid bugs caused by typos later.
### TEMPLATES
Similar to our FLAGS, this is where we define which handlebars template files our project includes. Again we hope to avoid typos by defining it in object form, which we will then re-use later while we're creating our UI.
## II. Create our ToDo typedef
We're going to be using [JSDoc](https://jsdoc.app/) to document our code as we go during this tutorial. This is entirely optional but is a very nice thing to do for future us as you return later to try and read your old code.
There's a concept of a [`typedef`](https://jsdoc.app/tags-typedef.html) in JSDoc which lets us define a complicated type which can be reused. Since we already know the shape of a single ToDo, we might as well define it.
```js=
/**
* A single ToDo in our list of Todos.
* @typedef {Object} ToDo
* @property {string} id - A unique ID to identify this todo.
* @property {string} label - The text of the todo.
* @property {boolean} isDone - Marks whether the todo is done.
* @property {string} userId - The user who owns this todo.
*/
```
## III. [Optional] Register a DevMode debug flag
Installing and using the [Developer Mode](https://www.foundryvtt-hub.com/package/_dev-mode/) module will allow us to have a few quality of life tools as we move forward. One of these is a way to register a debug flag that ensures we won't release code that has debug logs enabled.
### Add a log helper to ToDoList
```js=
static log(force, ...args) {
const shouldLog = force || game.modules.get('_dev-mode')?.api?.getPackageDebugValue(this.ID);
if (shouldLog) {
console.log(this.ID, '|', ...args);
}
}
```
### Register the module with Developer Mode
Developer Mode uses a [custom hook](https://foundryvtt.wiki/en/development/library-modules#follow-the-best-practices-for-module-apis) to serve an API to other modules which allows them to register as soon as possible.
```js=
Hooks.once('devModeReady', ({ registerPackageDebugFlag }) => {
registerPackageDebugFlag(ToDoList.ID);
});
```
### Using the log helper
Anytime you want to log something to the console, instead of doing `console.log('todo-list | ', 'foo')` and risking that be in a release, do `ToDoList.log(false, 'foo')` instead.
## IV. Wrapping Up
We've set up some things for our convienience in the next steps.
- Created a namespaced class for our module's general information to protect ourselves from other modules (and them from us).
- Added a typedef for our ToDo object.
- Created a logger helper to use Developer Mode's features.
<details>
<summary>Our Script so Far</summary>
```js=
/**
* A single ToDo in our list of Todos.
* @typedef {Object} ToDo
* @property {string} id - A unique ID to identify this todo.
* @property {string} label - The text of the todo.
* @property {boolean} isDone - Marks whether the todo is done.
* @property {string} userId - The user who owns this todo.
*/
/**
* A class which holds some constants for todo-list
*/
class ToDoList {
static ID = 'todo-list';
static FLAGS = {
TODOS: 'todos'
}
static TEMPLATES = {
TODOLIST: `modules/${this.ID}/templates/todo-list.hbs`
}
/**
* A small helper function which leverages developer mode flags to gate debug logs.
*
* @param {boolean} force - forces the log even if the debug flag is not on
* @param {...any} args - what to log
*/
static log(force, ...args) {
const shouldLog = force || game.modules.get('_dev-mode')?.api?.getPackageDebugValue(this.ID);
if (shouldLog) {
console.log(this.ID, '|', ...args);
}
}
}
/**
* Register our module's debug flag with developer mode's custom hook
*/
Hooks.once('devModeReady', ({ registerPackageDebugFlag }) => {
registerPackageDebugFlag(ToDoList.ID);
});
```
</details>
Next Step: [Writing the Data Layer](/hxB4-nbQRCyPDbPCsqTupw)
{%hackmd io_aG7zdTKyRe3cpLcsxzw %}