nchaloult
commented
4 years ago I love this idea! I think it's much more modular and expandable than our current "list of strings" approach. You're right that it would definitely make implementing more features like the ones you've mentioned much easier.
We've both determined via private messaging that you have a strong vision concerning how to implement this idea in a timely manner. I've also got some polishing touches that I'd like to make to the application in other areas (still knocking out some UI polish things). We should work on our respective tasks in parallel; I don't want to get in your way and work on top of you by contributing to this idea's implementation. Are you alright with making this idea come to life on your own?
ralph-dev
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:
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}] }]