Feedback: Random notes

[cmgriffing]

Fantastic idea with this project. A couple things came up while I was looking at this on stream. I realize this is an MVP, so some of this may already be on your roadmap. I just wanted to show some support and share some thoughts.

In no particular order:

• Allow importing a project from GitHub/GitLab/etc. It would be nice to be able to author everything in an editor of choice but not have to upload each file individually.
• Implement some Markdown/Mermaid rendering for the reviewers view. The Mermaid support would be good for architecture review.
• Allow companies to integrate their transactional mailing provider(Sendgrid, Postmark, etc) by pasting an API key and sender email address instead of making them copy/paste an email template into their email client.

Again, great idea. Looking forward to progress. Feel free to close this Issue whenever you like.

[CharlieDigital]

Great ideas; the Markdown was already on my roadmap.

Not sure how many folks would trust sharing their mail API keys, though.

[CharlieDigital]

Added support for Markdown with syntax highlighting.

[warrengalyen]

Like @cmgriffing mentioned, importing files would be invaluable.

• Add ability to import files from an entire git repo from multiple platforms or a Github Gist.
• Add ability to link to a git repo or gist (this is a better way IMHO so code examples are always in sync and easier to manage)

[CharlieDigital]

@warrengalyen What are the thoughts here in terms of folder structure? Should it replicate the structure? Or flatten it?

Have to think through this design a bit.

[warrengalyen]

@CharlieDigital I think it should replicate the folder structure if it exists just for compatibility. Ideally the person setting up the repo is going to keep the example simple with no sub folders, but you never know. Maybe for the first iteration keep rendering a flat structure like you already have to get it working and use a single parent node as a default folder in your DB. Lookup Adjacency List Model for storing tree data, this is a pretty common approach.

[Rucknar]

If i had a crack at adding in the capability to render a folder structure optionally, would that be something you'd support?
Checking before i spend any time on it, we use this to support interviews and being able to break apart the files so people can understand their heirachy for us would be helpful.

[CharlieDigital]

I'm for it!

Things to consider:

1. Backwards compatibility. With Firebase, I generally achieve this with different properties and render based on one or there other
2. Storage efficiency. Keep the Firebase docs light if possible
3. Optionality: Choose flat view (simple) or folder view depending on how complex teams are making their corpus

You may want to have a look at Quasar's tree: https://quasar.dev/vue-components/tree/

Or consider a simpler implementation that only supports one level of folders or possibly using "virtualized" folders based on name convention like folder/file.tsx that is purely visual.

The convention based one seems like the easiest one to achieve, IMO.