MLH-Fellowship / 0.2.1-readme-dirs

A web application that generates helpful project structures for public GitHub repositories
https://project-structure-readme.netlify.app/
MIT License
1 stars 1 forks source link

Tree Gen Architecture #34

Closed ralph-dev closed 4 years ago

ralph-dev commented 4 years ago

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[] => {

nchaloult commented 4 years ago

Not sure if it's too late to give my feedback and initial thoughts since I see a PR that mentioned this issue got merged into master....

Thoughts about formatDirName()

Should the formatDirName() func rewrite take the length of the comment into account? In other words, should

const spacing = `${' '.repeat(output.length - maxCharLengthOfLevel)} `;

be changed to

const spacing = `${' '.repeat(maxCharLengthOfLevel - (output.length + comment.length))} `;

?

Also, I think that naming a variable output without it actually being the variable that the function ultimately returns is confusing. Perhaps consider renaming the output variable to something like dirRelativeLink or dirSection?

Thoughts about the new Tree Core architecture, or Tree Gen structure

Are you proposing that a list of the following objects be maintained, one object for each line in the generated tree printout?

{
maxCharLengthOfLevel: number - Will help us calculate spacing for comments,
numberOfFoldersPerLevel: number,
numberOfFilesPerLevel: number,
}

What are your plans for keeping the values in each of these objects consistent? For example, if there's only one line in the entire tree printout where the corresponding object's numberOfFoldersPerLevel key equals, say, 3, and that line then gets deleted, will any of the values in the other objects need to be updated? In other words, is it possible for any updates or deletions of lines in the tree printout displayed on the page to knock your Tree Core data structure out of sync?

ralph-dev commented 4 years ago

@nchaloult I will update the TreeCore and TreeGen architecture accordingly the cool part is that TreeGen doesn't need to be re-created on every single deletion :)