What’s For Supper is a single page cross platform web app that simplifies the process of meal planning. It will adapt to your family’s preferences, while keeping a history of recent meals to not over-suggest. The application provides a low friction way for a family to plan meals. Families are given a single recipe at a time and asked if they would like to make that suggested supper. If they would like to make the supper, the app can bring up an associated ingredients list or recipe. If they do not want to make the suggested supper, the app will suggest another recipe.
The application will adapt the suggestions provided over time according to the user’s preferences. While it will try to avoid suggesting the same recipe too many times in a row, the suggestions will take into account a user’s preferences(meal ratings) in food choices to better suggest meals.
It will:
- Remove five or more minutes a day on deciding what’s for dinner
- Save time for 130 million families in the US every evening
- Encourage cooking meals for dinner rather than going to restaurants
Building is only supported on linux currently. Windows can probably be used, but continue at your own risk.
CI tests are run against the latest lts of the official node docker image, but it has been verified to build on both Arch and Ubuntu
The only dependency that must be manually installed is Yarn. We are building with the latest stable release at the time of writing, v1.21.1. Follow the instructions for your distribution to install.
To install project dependencies, from the project directory run:
This will download all required libraries and dev tools.
To start developing, run:
This runs a server that will watch your project for changes and automatically reload changes. The page is served from http://localhost:3000
When running in this mode, devtools are injected and reported errors are flagged as debugging.
To build an optimized build for deployment, run:
The finished build will be in the build folder. This build is designed to be served from the root of the server. If this is not what you want, see !19 for an example to build for some other location.
This is good for testing that the project can be built, but for production, releases should be downloaded from Gitlab CI instead of manually built. This ensures that the project is clean built in a consistent environment from only committed code, and that the build can be found later if needed.
After a merge to master, a build job will be triggered. When the job completes, the build should be available to download here.
Branches for different server roots can also be used, which is needed for things like student servers. A merge request such as !19 makes it easy to deploy, as there is a button to rebase to current master, which will also trigger a build.