GIT-USERNAME-HERE REPO-NAME-HERE APP-NAME-HERE PUT-TECH-STACK-HERE CLIENT-DEPLOY-URL-HERE
PUT-TECH-STACK-HERE
Explore the docs »
Report Bug
·
Request Feature?
This will be a comprehensive README for the sake of both prospective employers and fellow cohort peers, and whomever else would be interested in some of the techniques I've learned creating my frist Fullstack application. As a bonus, this README has some interesting implementations, though I won't address them here. Enjoy!
This README will systematically go over the entire app from the top level to the bottom layer, so I'll provide links to various sections for convenience.
The Public folder is nothing special, besides the custom favicon and (as I'll note later) some imported CDNs in the head of index.html for a few Google Fonts.
As an aside, it's actually faster (from a runtime perspective) to import fonts via CDNs, as apposed to importing them directly into stylesheets
[ config.js ] - this is essentially where I store "environment" variables. One important thing to know is that React has a built-in NODE_ENV variable that is set automatically when running scripts:
- Run Start:
NODE_ENV = developement - Run Build:
NODE_ENV = productionKnowing this, you can take advantage and set up conditionals based on the already-available
NODE_ENV. A major advantage is setting up API urls. When exporting like this...export default { ...config };
... you can access variables like this...
import config from '.../config.js'; ... await fetch(config.API_ENDPOINT)
[ index.js ] - bog-standard React App-wrapper using BrowserRouter [ setupTests.js ] - configuration for Enzyme testing
Fairly straight-forward Sass setup, with a simple reset and global stylesheet imported into the root index file. I won't get into Sass here, but know that I broke-out individual mixins to be used as imports in isolated [ .scss ] files
This is at the root level, but it's use is important in understanding the syntax used throughout the app. I won't go too in-depth, but essentially what's going on is it's creating a global alias for the [ src/ ] file directory. The side effect is that you can re-factor local imports:
/* someComponent.js */
import { PostService } from '../../../../../src/services';
...to...
import { PostService } from 'src/services';For more info on the jsconfig.json, check out the docs HERE!
Not strictly necessary, but this can help prevent typos, along with making changes to the database less tedious to update throughout the app.
You may have already noticed that there are actually many [ index.js ] files peppered throughout the app. These are known as "barrel" exports, and have a few advantages when dealing with a complex file-directory. The index file in the [ components ] folder has a short explanation, but I'll also put it here:
/*
|------------------------------------------------------
| BARREL EXPORT FILE
|------------------------------------------------------
| How-To barrel-export components:
| export { default as Comp1 } from './comp1/comp1.js' (omit .js)
|
| Why? Readability and (to an extent) testing:
| import { Comp1, Comp2, Comp3, Comp4 } from './components'
| import { Route1, Route2, Route3, Route4 } from './routes'
*/
export { default as LoginForm } from './loginForm/loginForm'
export { default as Header } from './header/header'
etc...You can see this in action in [ app.js ]:
Note that the import doesn't point to the index file. Node perceives [ index.js ] files as points of entry and the default file to grab exports from, essentially making it an implicit file in import statements
There's not much to say here, these essentially just import and render components, acting as entry points to component trees. However, I'll briefly cover...
1. Private/Public-Routes: This serves as a UX enhancement, both preventing users not logged in from accessing the app, and already logged in users from accessing the Login page. 1. PageNotFound: Standard inclusion, and in the case of this version, you can access this page vie the "Gigs" page as this is a feature not yet implemented.