mlh-fellowship / 0.2.1-readme-dirs Goto Github PK

WARNING: I am not trying to classify these folders by project or else it defeats the whole purpose of our application. This list is just to reference where these came from (The descriptions should apply globally and not be project-specific)

??? = Confused what right description is
X | Y = Name can have two naming conventions

StackOverFlow Suggestions

src/: "source" files to build and develop the project. This is where the original source files are located, before being compiled into fewer files to dist/, public/ or build/.
distributable/ | dist/: "distribution", the compiled code/library, also named public/ or build/. The files meant for production or public use are usually located here.
assets/: static content like images, video, audio, fonts etc.
lib/: external dependencies (when included directly).
test/: the project's tests scripts, mocks, etc.
node_modules/: includes libraries and dependencies for JS packages, used by Npm.
vendor/: includes libraries and dependencies for PHP packages, used by Composer.
bin/: files that get added to your PATH when installed.

React
fixtures/ - Mock Objects???

Docsify
.vscode/ - Visual Studio Code IDE Editor Settings

Babel
.circleci/ - Circle CI is a Continous Integration Platform
.codesandbox/ - CodeSandbox is an Online IDE
.github/ - Github Supported Markdown Files like Changelogs, Issue Templates etc
packages/ - A list of Packages that this repository maintains
codemods/ - An Automatic Way to conduct Migrations of Codebases to new formats

Sentry
mocks/@sentry

React-Native

Android/ - Android Native Code Lives
IOS/ - IOS Native Code Lives
IntegrationTests | e2e/ - End to End Integration Tests
bots/ - Code Analysis Bots that act like Repo Watchers
flow/ - Where Code Types are kept (Similiar to TypeScript's Types folder)
jest/ - JavaScript Testing Framework (Where Tests are kept)
keystores/ - Android Debug & Release Keystores for Playstore Deployments

Atomic Design Principles | https://atomicdesign.bradfrost.com/

atoms/ - Single Layer Components
molecules/ - Collection of Atom Components to make a complex component
organisms/ - Assemblies of molecules functioning together as a unit
templates/ - Page Level Objects that define the Layout and Structure of a Page
pages/ - Specific Instances of Filled In Contentful Templates for a Complete Visual

Graphl API
Definitions could be more clear but at least to have something
/
|-- controllers # Controllers, used to resolve GraphQL fields.
|-- errors # Error classes thrown.
|-- gates # Permission gates, used for permission checking.
|-- graphql # GraphQL definitions.
|-- enums # Enum definitions.
|-- inputs # Input definitions.
|-- types # Type definitions.
|-- middlewares # Express.js middlewares.
|-- migrations # Migration scripts, useful for production, not needed if you run from a freash start.
|-- models # Database models.
|-- providers # Service providers.
|-- resources # Text resources.
|-- rules # Permission rules, these are detailed rules to be used within gates.
|-- scripts # Setup scripts etc.
|-- util # Utilities.
|-- validators # Validators, used to validate inputes.

Other
Cypress/ - A Front-End JavaScript Testing Framework

Right now, our project's README is the default one generated for us by the create-react-app utility. I'm thinking that we should scrap our current README & brainstorm ideas for what relevant information we should include in a new README.

When I think about our new README's contents, the first things that come to my mind are:

• Some kind of GIF/screenshot of the UI, or of the app in action
  • So people can quickly get an idea of what this project is and how it works
• Description / Motivation section
  • What problem are we trying to solve?
  • Why is this problem worth solving? In other words, if we solve this problem, who will benefit from our solution?
  • What are we building, or what have we built?
• Technology Breakdown
  • What tools & technologies did we use?
    • What purpose is each of those technologies serving?
      • For example, we've used React to build our front-end web application
    • For some of our choices, it might be worth writing a couple of sentences about why we chose them as opposed to some popular alternatives
    • We should highlight which of our technologies were introduced to us during our hackathon kickoff

This new README might be one of the last things that we work on during this hackathon, but I thought it was worthwhile to go ahead and create an issue about it now so that it stays on our minds.

If we use Github's API to traverse the project structure of a public repo, one of the things that we get back are absolute paths to each file in the repo as strings. Given a list of these file path strings, we need to generate Markdown with a "tree printout," similar to that of the tree command.

If we recognize the name and placement of a particular directory, we should include a comment about what that directory is for in this printout. For instance, if we find a src/ directory at the root of the repo, we should include a statement about how source files live there, as opposed to other types of files in the repo.

We need to ability to store some information once for styling reasons like comment alignment in an efficient way. Storing this in Tree Core would lead to issues with duplication of existing information and is quite inefficient.

Proposal:

Tree Gen Structure that uses Tree Core to calculate the structure below:

Level is calculated based on index on Array
[{
maxCharLengthOfLevel: number - Will help us calculate spacing for comments,
numberOfFoldersPerLevel: number,
numberOfFilesPerLevel: number,
}]

maxCharLengthOfLevel

const formatDirName = (path: string, dirName: string, comment: string, maxCharLengthOfLevel: number): string => {
  const output = `📂 [${dirName}](./${path})`;
  const spacing = `${' '.repeat(output.length - maxCharLengthOfLevel)} `;
  return output + spacing + comment;
};

This code would live in
const generateTree = (paths: TreeCore[]): string[] => {

This architecture proposal is just for the implementation of Tree Core ability to delete specific parts of the tree and have it re-appear with an undo button

Requirements

• Support Deletion of any Line on the Tree Core
• Support Undo of most recent deletion on Tree Core
• Support Deletion of entire DepthLevel ( Folder )
• Support Undo of entire DepthLevel ( Folder )

We can implement a variable that holds a list of Tree Core Objects in FIFO format (Queue).

We can delete any line and push it into the DeleteQueue.
We can undo any line by popping it out of the DeleteQueue.

We can delete an entire depth level by filtering through the Tree Core for a specific depth level.
We can undo an entire depth level deletion by filtering through the DeleteQueue for a specific depth Level.

The Unicode character for the last item in a directory should be different.

You are currently using BOX DRAWINGS LIGHT VERTICAL AND RIGHT for the last item, but it might be more aesthetically pleasing to use BOX DRAWINGS LIGHT UP AND RIGHT or other L-shaped symbol that fits.

Example:

├── client
├── config
├── db
├── docs
├── services
├── utils
└── tests     # different character for last item

Relates to: #28

After thinking about our Tree Core Structure all day I have come to the conclusion we can better represent our Tree Core to support a multitude of features aside from just displaying markdown.

Architecture Opens Up Possibilities:

• Line by Line Deletion with Undo (This will actually be done by a seperate DeleteQueue System for DeCoupling purposes)
• Folder & File Clarification through an accessible API
• Comment Alignment on a PER LEVEL BASIS

Instead of using a list of strings as our visual display system we can use a list of JSON objects that match the schema below:

The array itself outlines the positioning of how things are displayed
[{
// The Path String of the Folder / File (For Display / Linking Purposes)
text: string,
// The Director Level from Root (For Accordion Purposes / Comment Alignment Purposes /
Organization Purposes, if we want all single level at top, double level below etc)
depthLevel: number,
// If the line is a Configuration Hidden file (.config) or a File or a Folder (For Icon Type Purposes)
fileType: ENUM {Hidden, File, Folder},
// To allow for Comment Editing (We need to store the edits here)
comment: string,
}]

const depthLevel = path.split('/').length; (This calculates the DepthLevel but we need to store a global max length per Level to understand how to adjust spacing for everything on that level)

We can have a utility function that does DepthLevel * FIXED_COMMENT_SPACING to calculate the spacing of comments along with any level.

@nchaloult brought up a great point about

1. Deleting getting Tree Gen out of sync.
2. It made me think about ACCESS times in our current implementation.
   Thus I am proposing Tree Core V2 which merges Tree Gen and Tree Core Together in a structure that doesn't require as much updates and is always in sync!

The array itself outlines the positioning of how things are displayed
[{
// The Path String of the Folder / File (For Display / Linking Purposes)
text: string,
// The Director Level from Root (For Accordion Purposes / Comment Alignment Purposes /
Organization Purposes, if we want all single level at top, double level below etc)
depthLevel: number,
// If the line is a Configuration Hidden file (.config) or a File or a Folder (For Icon Type Purposes)
fileType: ENUM {Hidden, File, Folder},
// To allow for Comment Editing (We need to store the edits here)
comment: string,
// To allow for deletion tracking without the need for a DeleteQueue
deletedOrder: number field where if it equals 0, it hasn't been deleted but if it has a number like 1
then it was the first thing to be deleted, then 2 for the second thing. If you delete a batch level
then every file will have 1 entirely.,
// NEW FIELD (Holds Everything inside this folder object)
subTree: [{REPLICA OF EXISTING}]
}]

A cornerstone feature of our application is a display for the "tree printout" that our app generates once a user provides a public GitHub repo URL.

Living Feature Checklist

I just remembered checklists in Markdown (even though I learned about them like 2 days ago during the "intro to GitHub" course that we took through TalentLMS), and now I found an excuse to use them 😃😜

• Clean and readable "box" to display the generated tree
  • Front and center on the web page
• "Copy to clipboard" button

Stretch Goals

• "Delete" button next to each line of the generated tree
  • If users don't want to include particular folders in the generated output that they slap on their project's README, they should be able to conveniently remove those lines from the generated output
• "Undo" functionality (if we implement the "delete" buttons)

In private calls, the team discussed front-end-y bits concerning how our app should look and behave.

Discussed Attributes

The following are details that we discussed which we need to implement and make consistent site-wide.

• Color scheme
• Font choices
• Overall page layout and element placement
• Overall design language (this is so vague but idk how else to describe this)
  • What shapes and patterns we're going to use

When we're generating the "tree printout" for a public GitHub repo, if we recognize any common folders, we should include little comments next to those folders in the printout.

For instance, if we find a folder called src/ at the root directory of the repo, then that folder should have a comment next to it like this:

📂 public
📂 src # Source files
├── 📂 Components
...

This issue involves implementing this functionality, as well as deciding what common folders we will look for and what comments we should put next to them in the generated printout.