This is a basic React app starter which includes a server built with the Express library and a SQLite3 database. My intention here was to create a full-stack React starter repo with minimal non-npm dependencies required, e.g. having a database daemon running on your computer with all the outside setup that comes with that.
git clone https://github.com/acdibble/react-startercd react-startercp .env.clean .envnpm inpm run client-dev- Open a new terminal tab or window
npm run server-dev
You can navigate to http://localhost:8080 in a browser to view the client.
When you save any files that contain client code, the page will automatically
refresh with those changes. All requests to /api endpoints are proxied to the
Node server that is running on port 3000. This port is configurable in the .env
file included with this repo. From this file, you can manage the environment
variables for the project in this file.
This repo comes with a basic SQLite database. You can view the schema in the database folder. It is extremely basic to allow basic scaffolding of the app.
There is one database query already written as an example for interacting with SQLite from Node.
To interact with the sqlite database outside of the app, I recommend getting the SQLite3 command line shell.
The front end is built on React 16, Babel 7, and Parcel. Linting standards are enforced according to the Airbnb styleguide.
There is a basic structure in place for displaying todos from the database as an example of how to pass props down through multiple component levels.
The server uses the Express library to serve up the static files and includes one internal API route which is used to fetch todos from the database and return them back to the front end.
Why not Babel on the server? Just because it's not strictly necessary. There is only one Node environment you have to worry about, so unless you want to use bleeding-edge JS proposal features, it's an unnecessary complexity.
There are some tasks that can be accomplished with what is already in place. All this app currently does is pull todos from a database and display them to the user. Improvements that could be made include:
- Giving todos a completion state and conveying that state to the user
- Allowing the user to toggle a todo between completion states
- Giving the user a way to add/remove/edit todos to/from/in the DB
- Creating a multi-user environment and allowing users to submit personal todos and managing the various views that that entails
All of these tasks include database migrations. I would recommend finding your preferred database before getting too deep into migrations or schema design.