47 lines
2.9 KiB
Markdown
47 lines
2.9 KiB
Markdown
|
# Source Code for our OBS Layouts
|
||
|
|
|
||
|
|
This is a NodeJS project that hosts a set of pages that we'll potentially be using as part of our OBS layouts for streaming.
|
||
|
|
|
||
|
|
## Development
|
||
|
|
|
||
|
|
You can use the `deploy.sh` script to start up the container in development mode.
|
||
|
|
|
||
|
|
```
|
||
|
|
./deploy.sh dev
|
||
|
|
```
|
||
|
|
|
||
|
|
This will handle starting a new container of Next.js with all required packages for the site in development mode. You should use this if you're planning on running the site using production mode later so you can see changes to your code in real time and test any backend changes.
|
||
|
|
|
||
|
|
Keep in mind that you should **never** host this site in development mode publicly. This sentiment reflected in the documentation for Next.js.
|
||
|
|
|
||
|
|
## Production
|
||
|
|
|
||
|
|
You can also use the `deploy.sh` script to start up the container in production mode.
|
||
|
|
|
||
|
|
```
|
||
|
|
./deploy.sh build
|
||
|
|
./deploy.sh start
|
||
|
|
```
|
||
|
|
|
||
|
|
The `build` parameter will generate the necessary static assets for the site, including any static pages and JSON. The `start` parameter starts up a production server. If the build fails, you won't be able to start a production server. So, if you decide to issue something like `./deploy.sh build && ./deploy.sh start` just keep that in mind.
|
||
|
|
|
||
|
|
## Personalization (Forking)
|
||
|
|
|
||
|
|
You're absolutely free to fork this code and make some modifications for your own usage! I simply ask that you not host something that looks like it's just my own personal layout somewhere else, and that you link at least the original source code. Additionally, if you intend to keep [Mutant Standard emoji](https://mutant.tech/), please do not forget to include the Creative Commons license statement.
|
||
|
|
|
||
|
|
### `pages/`
|
||
|
|
|
||
|
|
The project itself is split into `pages/` and `components/` mostly. Pages are used to define both the routes and the site pages themselves. They're the most high-level part of the site's structure, since they import code from `components/`.
|
||
|
|
|
||
|
|
### `components/`
|
||
|
|
|
||
|
|
Unless you are making *major* changes to a page, you likely will want to edit the code in components. This is where you can edit a lot of the JSX that's defining the different elements of each page. Think of it as editing sections of a template.
|
||
|
|
|
||
|
|
### CSS
|
||
|
|
|
||
|
|
It's also likely that if you're editing data and components, you'll want to change the theming and styles of things. This project uses [tailwindcss](https://tailwindcss.com/), which is quite unique amongst most CSS frameworks.
|
||
|
|
|
||
|
|
Without writing an intro to the framework itself, I'll give a brief summary. If you take a look into the components, you'll notice that tags tend to have a *lot* of class names. Tailwindcss uses these class names to apply specific styling to elements, rather than making sets of CSS files to define styling based on classes and ids.
|
||
|
|
|
||
|
|
If you want to change the color palletes of things, you should look at `tailwind.config.js`. This file can define quite a few other things throughout the CSS framework, but I'll leave the investigation of that to some reading through of their documentation.
|