Prepare app for development

.github/code_of_conduct.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at inquiries@marquiskurt.net. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+<https://www.contributor-covenant.org/faq>

.github/contributing.md

@@ -0,0 +1,92 @@
+# Hyperspace Contribution Guidelines (version 2)
+
+Thank you for contributing to Hyperspace! To make the contribution process quick, smooth, easy, and fun, we've devised a set of guidelines. Please consult these when making a pull request, issue, etc.
+
+## General Code Guidelines
+
+These guidelines apply to code that is written in Hyperspace.
+
+### Declare styles with components (NEW)
+
+Hyperspace 1.0 uses the [Material-UI](https://material-ui.com) framework to create beautiful design that scales across devices. Part of using this framework includes defining styles right inside of the code as [JSS](https://material-ui.com/getting-started/faq/#do-i-have-to-use-jss-to-style-my-app). As such, we recommend adding a file dedicated to your styles in the component's folder and writing in the styles accordingly.
+
+### If possible, use a type
+
+Hyperspace uses custom types via [TypeScript](https://www.typescriptlang.org/) to specify variables, parameters, and other parts of code to prevent ambiguity. If it is possible to use an existing type from `src/types` (or other types from project libraries) or make a new type, use it. Otherwise, use `any` as the type.
+
+Suffice to say, this also means that new components or code _should_ be written in TypeScript files (.ts, .tsx) unless there is a compatibility issue that prevents this from working properly.
+
+### Keep code organized
+
+The Hyperspace structure is organized based on utilities, components, tests, and other types of files to make everything easy to locate. Please try to keep this organization when making a new component or test.
+
+## Issues
+
+These guidelines apply to issues on GitHub.
+
+### Be as descriptive and concise as possible
+
+So that Hyerpspace contributors and developers can better understand what the issue or request may be, issue descriptions should be concise but also descrptive. Refrain from writing an issue in a convoluted way that confuses others.
+
+Additionally, if you feel using a screenshot or video will better illustrate your description, add them in conjuction with (or to replace) the description. Remember to consult the [Screenshot Guidelines](#screenshots).
+
+### Label your issue during creation
+
+Issues are categorized by types such as `bug`, `enhancement`, `question`, etc. by contributors that can access labels. Since it isn't possible to tag an issue during creation, prepend the tag to your issue's title.
+
+> Example: [Enhancement request] Support settings sync with TorielDB
+
+## Pull Requests
+
+These guides apply to pull requests on GitHub.
+
+### Describe all of your changes
+
+Pull requests generally include many changes that address a particular problem or a set of problems. Explain all of the changes you made, but refrain from listing all of these changes as commit messages.
+
+> Example:
+> This PR makes the following changes:
+>
+> - Custom emojis from the user's server can be used in a post by typing its shortcode or inserting it through the new emoji picker*.
+> - Posts and profile names display custom emoji.
+> - A new utility, emojifyHTML, will automatically replace emoji shortcodes with img elements.
+
+### Reference existing issues and PRs
+
+If applicable, pull requests will reference the issues they are fixing in the description. This helps organize contributions in a few ways:
+
+- Automates closing issues when they are fixed
+- Verifies that the pull request fixes the issue(s) in question
+- Makes a reference in the issue's thread for context
+
+If there are any documented issues that the pull request addresses, reference them in the description of the pull request.
+
+> Example:
+>
+> - Use TorielDB to sync data (fixes #1)
+
+### (Optional) Sign-off your code
+
+Hyperspace contributors try to credit pull request contributors in release notes as a way of saying thanks. Another way to ensure that we credit the right person if by signing-off your code. This can be done either in the pull request's description or the latest commit pushed to branch linked with the pull request:
+
+```
+Signed-off-by: Your Name <youremail@email.com>
+```
+
+This isn't required but is good practice to confirm that you wrote the code so we can credit it accordingly.
+
+## Screenshots
+
+These guidelines apply to screenshots that are used for reference in issues and/or pull requests.
+
+### Respect the post author's visibility
+
+Mastodon supports posting to four different visibility levels. As a means of respecting privacy, please keep in mind the following:
+
+- Do not post a status published as a direct message, followers-only, or unlisted status _unless_ you have explicit permission from the status author.
+  - If you made a direct message to yourself to demo a feature or fix a bug present in a post, you do not need to worry.
+- If you are unsure whether a public status should be included in a screenshot, consult the post author.
+
+### Ensure screenshots are clear
+
+Screenshots are often included to help illustrate or demonstrate a point with an issue or pull request. It may be difficult to understand the screenshot's purpose if the image is too small or distorted. Ensure that all screenshots are clear and visible.

.gitignore

@@ -59,3 +59,6 @@ typings/
 
 # next.js build output
 .next
+
+# VSCode dirs
+.vscode/

package.json

@@ -1,14 +1,19 @@
 {
-  "name": "hyperspace-v1",
-  "version": "0.1.0",
+  "name": "hyperspace",
+  "version": "1.0.0",
   "private": true,
-  "dependencies": {
+  "devDependencies": {
+    "@material-ui/core": "^3.9.2",
+    "@material-ui/icons": "^3.0.2",
     "@types/jest": "24.0.11",
     "@types/node": "11.11.6",
     "@types/react": "16.8.8",
     "@types/react-dom": "16.8.3",
+    "@types/react-router-dom": "^4.3.1",
+    "megalodon": "latest",
     "react": "^16.8.5",
     "react-dom": "^16.8.5",
+    "react-router-dom": "^5.0.0",
     "react-scripts": "2.1.8",
     "typescript": "3.3.4000"
   },

src/tests/App.test.tsx

@@ -1,9 +1,14 @@
 import React from 'react';
 import ReactDOM from 'react-dom';
-import App from './App';
+import App from '../App';
+import { HashRouter } from 'react-router-dom';
 
 it('renders without crashing', () => {
   const div = document.createElement('div');
-  ReactDOM.render(<App />, div);
+  ReactDOM.render(
+    <HashRouter>
+      <App />
+    </HashRouter>
+  , div);
   ReactDOM.unmountComponentAtNode(div);
 });