### Introduction:

The seeder is used to seed the Firebase Emulator with randomized and fake user data for the sake of testing and experimenting. 

It seeds the following collections:

- Facilities
    - Providers
    - Admins
- Patients

Along with seeding the accounts under the Authentication tab/suite of Firebase.

FakerJS ([see more](https://fakerjs.dev/)) is used to generate faked data.

### Lifecycle:

1. 100 (default, can be changed in the codes loop condition) Patient documents are created with the necessary faked data and upserted to Firestore `Patients` collection.

2. 10 (default, can be changed in the codes loop condition) Facility documents are created with the necessary faked data and upserted to Firestore `Facilities` collection.

    - Everytime a Facility is created, 20 (default, can be changed in the codes loop condition) Provider documents are created with the necessary faked data and upserted to the `Facilities/{Facilities document ID here}/Providers` collection.

    - Everytime a Facility is created, 2 (default, can be changed in the codes loop condition) Admin documents are created with the necessary faked data and upserted to the `Facilities/{Facilities document ID here}/Admins` collection.

After Firestore seeding, Auth seeding begins as follows:

1. An *ACTIVE* account is created for every document in the `Patients` collection, using the same document ID.
    
    - The user's custom claim is also updated to portray `{ role: 'patient' }`

2. An *ACTIVE* or *DISABLED* account (depending on the `isPendingApproval` flag, which is randomized also) is created for each Provider document in the `Facilities/{Facilities document ID here}/Providers` collection, using the same document ID.

    - The user's custom claim is also updated to portray `{ role: 'provider', facility: { name of Facility goes here } }`

3. An *ACTIVE* account is created for every document in the `Facilities/{Facilities document ID here}/Admins` collection, using the same document ID.
    
    - The user's custom claim is also updated to portray `{ role: 'admin', facility: { name of Facility goes here } }`

As the seeder progresses, the results are being outputted to the console through the use of Firebase admin SDK's `logger`.

> NOTE: Due to Authentication not allowing duplicate emails for different accounts, we use an array of strings called `emails` to store already saved emails and is checked on an entity creation for existing email, prompting the randomizer to generate a new entity if email exist.

### How To Use:

> Before using, assure that the `lib` folder located in the [functions](../../functions/) is deleted or this will cause the Cloud Functions to load on Emulator start. The Cloud Functions consist of triggers that listen to document creation, triggering on every document creation, that may or may not send a plethora of emails to fake emails. This could be problematic, so to avoid this, just make sure `lib` is deleted so that Cloud Functions are not loaded on Emulator start.

If your `lib` folder is deleted, then there's multiple scenarios you consider:

1. If you do not have a [seed](../../seed/) folder, which is used to seed the Emulator automatically on start (this is generated by exporting the data on Firebase Emulator teardown) or you want to seed the database repeatedly with more data (won't save on teardown), proceed to [Initial Data Seeding](#initial-data-seeding).

2. If you have a [seed](../../seed/) folder, but want to generate a new seed for Firebase Emulator start, proceed to [Initial Data Seeding](#initial-data-seeding).

### Initial Data Seeding:

If you accidentally deleted the `seed` folder, do not have a `seed` folder or want to make your a new `seed` folder or your own `seed` folder aside from the teams (make sure to include the `seed` folder in the root `.gitignore` or else you'd conflict with other members commits), you can do so by:

1. Delete the [lib](../lib/) folder if it exists.

3. Manipulate the `start` script in the root [package.json](../../package.json) to be "firebase emulators:exec --export-on-exit=./seed --project=neurotask-afbd7 --ui 'ng serve'".

3. Run `npm start` in the root directory of the project.

4. Run `npm run seed` in the [functions](../../functions/) directory and wait for completion (denoted by the logs in the command line).

5. Change the `start` script in the root [package.json](../../package.json) to be "firebase emulators:exec --import=./seed --project=neurotask-afbd7 --ui 'ng serve'".

When you exit the Firebase Emulator, you'll see a `seed` folder created in the root directory which contains metadata that Firebase Emulators will use to seed the Emulator suite on the next startup.