Web app that helps schools and nonprofits connect students with expert mentors and volunteer tutors.
OTHER License
** Attention: This project needs your help! Message me if you're interested in becoming a contributor.**
** Currently: Working on migrating from Firebase to the open-source Supabase alternative.**
Tutorbook is the best way to manage online tutoring and mentoring programs.
It's an online app used by organizations (i.e. nonprofits, K-12 schools) to:
Students use Tutorbook to:
Parents and teachers use Tutorbook to:
This is a high-level overview of the various resources ("things") manipulated by and created through the app. Resources may also specify "tags" (filterable attributes) that are totaled daily for our in-app analytics.
Note: This section is not a complete technical definition of our data model.
Instead, please refer to
lib/model
for always up-to-date Typescript data model definitions.
User
A user is a person. This person could be a tutor, mentor, student, admin or all
of them at the same time. Those roles are not inscribed on each user but rather
implied by role-specific properties (e.g. a mentor will have subjects specified
in their mentoring.subjects
property).
Users also have role-based tags (tutor/tutee/mentor/mentee) that are set when:
tutoring.subjects
, theytutor
tag.tutor
in at least onetutor
tag.Role tags are never removed: once a user has been a tutor at least once, they will always be considered a tutor.
Org
An org is a school, nonprofit, or other business entity that is using TB to manage tutoring and/or mentoring programs.
Match
A match is a pairing of people (typically between a single student and a single tutor/mentor, but there can be group pairings as well). Matches are simply containers for meetings.
Meeting
A meeting is exactly that: a meeting between the people in a match with a specific time and venue (e.g. a specific Zoom link). In order to support complex recurrence rules, a meeting's time consists of:
rrule
to calculate individualrrule
. It isto
property).Upon creation, Tutorbook sends an email to all of the people
in the new
meeting's match with the meeting time, venue, and everyone's contact info.
rrule
). Set when the meeting isSummarized here are descriptions of common data flow patterns and design specs. These are some of the front-end design guidelines that TB follows in order to maintain consistency and display predictable behavior.
Recurring events are always a struggle to implement. There are many resources available that are meant to make implementing such recurrence rules easier.
TB's entire recurrence stack is quite simple:
RRULE
recur rules with support for eventrrule
.Editing and updating recurring meetings is intuitive:
RRULE
andRRULE
.TB uses Segment to collect analytics from both the client and the server. When defining events, I use Segment's recommended object-action framework. Each event name includes an object (e.g. Product, Application) and an action on that object (e.g. Viewed, Installed, Created).
TB also has in-app analytics features for orgs to use. It collects a few totals
every day (based on Algolia tags) and stores them in a Firestore subcollection
(/orgs/<orgId>/analytics
). Those totals are constantly being updated as API
requests come in (e.g. when a new user is created, TB increments the "Total
Users" statistic by one) and thus are always up-to-date. All of those totals
are based on filterable tags (e.g. "Total Users Matched") which allows admins to
view all the users/matches/meetings that have certain tags, answering questions
like:
There are two types of data entry forms used throughout TB:
Do the following (preferably in order):
#introductions
with who you are and how you can help (and what#development
channel pins for more information on how you canAlso feel free to check out our recently added tutorials/
directory for
additional information detailing different aspects of this project (e.g. tests,
deployment workflows, CI/CD, etc).
This project uses (please ensure that you're familiar with our tech stack before trying to contribute; it'll save your reputation and a lot of time):
I have very precise rules over how Git commit messages in Tutorbook's repository must be formatted. This format leads to easier to read commit history.
Please refer to the following documentation for more info:
Commit messages that do not adhere to the following commit style will not be
merged into develop
:
<type>(<scope>): <short summary>
Summary in present tense. Not capitalized. No period at the end.
Commit Scope: The page, API route, or component modified.
Commit Type: ci|docs|feat|fix|perf|refactor|test|deps|chore
The <type>
and <summary>
fields are mandatory, the (<scope>)
field is
optional.
Must be one of the following:
The scope should refer to the page, API route, or component modified. This can
be flexible however (e.g. the scope for a docs:
commit may be the README
).
Use the summary field to provide a succinct description of the change:
To setup a development environment for and to contribute to the TB website:
nvm
(our suggested way to use Node.js) on yournvm
is installed by running:$ command -v nvm
$ nvm i 16.13.0
$ nvm alias default 16.13.0
npm
by running:$ node -v
16.13.0
$ npm -v
6.14.7
$ sudo apt-get install libgtk2.0-0 libgtk-3-0 libgbm-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2 libxtst6 xauth xvfb
cd
into this repository locally by running:$ git clone https://github.com/tutorbookapp/tutorbook.git && cd tutorbook/
yarn
(our dependency manager for a number of reasons):$ npm i -g yarn
$ yarn
$ yarn dev
.env
file):Error [FirebaseError]: projectId must be a string in FirebaseApp.options
cd
into your desired component or lib utility, make your changes,develop
, push it to a fork of ourAll of the below scripts come directly from Next.js. In the project directory, you can run:
yarn dev
This command runs two scripts concurrently:
next dev
with the Node.js --inspect
flag on (useful for debugger
firebase emulators:start
to start the Firebase EmulatorOpen http://0.0.0.0:3000 to view the app in the browser
(note that TB uses 0.0.0.0
instead of the default localhost
for Intercom
support. The page will hot-reload if you make edits.
You will also see any lint errors in the console.
Open http://localhost:4000 to view the (locally-running) Firebase development console. Here, you can manually seed Firestore data and view GCP Function logs.
yarn build
Builds TB's service worker and runs next build
which builds the application
for production usage.
yarn start
Runs next start
which starts a Next.js production server. I have no use for
this right now because I'm deploying to Vercel NOW which handles that for me.
yarn analyze
Runs the build to generate a bundle size visualizer.
yarn lint
Runs all of ESLint tests. This should rarely be necessary because you should
have ESLint integrated into your IDE (and thus it should run as you edit code)
and I have Husky running pretty-quick
before each commit (which should take
care of the styling that ESLint enforces).
yarn style
Runs our code styling Husky pre-commit hook. TB uses Prettier to enforce consistent code formatting throughout the codebase.
A pre-commit hook is used to format changed files found on commit, however it is still recommended to install the Prettier plugin in your code editor to ensure consistent code style.