Directories

[thombruce]

Adds a directory list for listing files in a directory (and recursively nested directories).

Should also add...

• [ ] Capability to create and navigate to new document
• [x] Speaking of navigation, should remove navigation links (left as an exercise to consuming apps probably)
• [ ] Capability to delete a document
• [ ] ...

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

---

Internal use. Do not delete.

• [x] Tests passing
• [x] Coverage sufficient
• [x] Manual review
• [x] No A11y regression
• [x] Translations provided or not needed

[thombruce]

Have removed navigation, though am wondering if it's the right call...

1. If we provide links but no [...slug].vue and user does not overwrite slot, links will be broken unless user provides own [...slug].vue or custom page template
2. If we did also provide a [...slug].vue this could only show the contents of the file in a pre (or a textarea/CodeMirror input) and would likely want to be overwritten by the user anyway
3. If we simply don't provide links... the component isn't that useful by default

I think I do want to provide the default links (pointing to the filepath relative to the app's homescreen), but I am unsure whether or not to provide a default [...slug].vue. Sure, the links will be broken without one... but that might be the most desirable behaviour. Why? Because if the user does not provide a page file to match their expected file patterns, an error is probably more useful than a default page.

Meaning... the change I've just made should be reverted. Dang. Okay, I'll do that...

[thombruce]

At time of implementation I also thought... what if the user does just want a list without links? Obviously they could replace the slot with their own content to achieve this... which did slip my mind... but I've added a prop called links that will allow them to make that choice without having to overwrite the slot. By default, we do provide links.

[thombruce]

Two thoughts occur when thinking about creating new documents...

1. The user should be able to create these in a subdirectory too, should they wish
2. We should maybe display subdirectories differently, as an expandable list within our document list

Perhaps the user should even be able to create directories. Two buttons: One to create a document, another to create a directory.

As I did with the document list initially, I might implement this on Toodles first then port it backwards into TNT refactoring to meet more generalised needs. Toodles, for instance, needs to limit the scope of what documents can be created:

• todo.txt
• *.todo
• *.shop
• *.list

done.txt deliberately omitted because one wouldn't use Toodles to create this directly. Toodles might eventually add automatica creation of done-type files.

Ideally then, Toodles would open a submenu when creating a file with options to create a todo list, a shopping list, a generic list, a classic todo.txt document or a new directory. TNT's generic menu would likely just have "New document" and "New folder" options.

The user then also needs to be prompted to name the new document/folder. Could this be a good cause for a modal?

And then we need to determine whether we redirect to the newly created document or stay on the same page. I believe this should be configurable via a callback, however we should also decide on a default behaviour... I think the default should be to navigate to the newly created page. Justification: Even though this will presently navigate away from the directory list, the directory list could eventually be housed in a persistent sidebar that appears on every page anyway (or rather... is part of the app template with the page-rendering being adjacent to it in the view). I'd rather the correct implementation with temporary mild inconvenience than the incorrect one for short term comfort.

[thombruce]

I have this far ignored the utility of the withFileTypes option of fs.readdir()... but I believe it would be necessary (from TNT's perspective - Toodles could infer by lack of extension) to tell a folder apart from a document.

And speaking of Toodles, its filter will presently ignore folders entirely (it filters for filename matches inclusive of extension). We may need more options in terms of filtering various folders (or not) too.

And, short of deliberately adding a folder to an ignore list, we couldn't possibly know what folders to list and which to omit.

I mean, that is easily fixed. We can just add an ignore list to tnt.config.json. But it does mean that if Toodles is placed and executed at the top of a deeply nested directory structure... we would inevitably list a lot of folders we aren't necessarily interested in.

We could ignore certain folders by default (node_modules for instance, .github for another) but...

Well even if we enabled the user to ignore the nested folders they aren't interested in seeing, we would need to also allow them to undo this (probably from the settings page). And yeah, I think that's probably the best option. I don't think it's going to be applicable to every app though; Toodles, certainly, but...

Let's at least have the problem before we figure out how to fix it. For now, for my purposes, the full directory list (with certain sensible automatic omissions and a hide/unhide function) will be generally useful.

[thombruce]

Could be useful: https://github.com/mihneadb/node-directory-tree/tree/master

fs.readdir returns a flat array which would require some work to properly structure as a tree for navigation...

...and this library does that work.

[thombruce]

So withFileTypes doesn't actually return anything particularly useful:

{
  "name": ".nuxt",
  "parentPath": ".",
  "path": "."
}

We can't infer from that what is and isn't a directory. There are methods we can employ to achieve this but... let's not reinvent the wheel. I think this is a good case for that directory-tree library.

[thombruce]

With use of directory-tree, we are now displaying a directory tree.

We still do this on the index page of Toodles and would prefer it to be confined to a menu.

We still don't have a way to create a new document, delete an old one or rename an existing one.

And the application currently won't respond to changes made outside of the application (e.g. a document being created while the application is open - though I believe a page refresh would account for this). That is also true of the open todo documents themselves in Toodles - we don't watch for any changes outside of the application. I will probably create a separate issue to address this.

[thombruce]

Of the features still absent, deletion of folders/documents should be the easiest to implement as we do not need to create a form to do this (as we will for create and rename - these also need to be path-aware).

However... I wouldn't want to implement deletion without also implementing creation.

Right now we can do either of these from outside of the application, so there is an argument that we can publish as is, as an in-development feature and handle the control mechanisms as a separate issue.

I think that's exactly what we will do. This is already useful, if not feature-complete.

[thombruce]

One thing I might want to do is rename TntElectronDirectoryList to TntElectronDirectoryTree so that the tree structure is better semantically implied by the component name. I think I'll do that and then, pending review, we can publish.