Directory Controls

[thombruce]

closes #85

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]

Contrary to some of my later discussion on #85, the details/summary component(s) are remaining open. It's just that when I reobtain the directory list and assign it to my tree state... the order is sometimes different.

Why is the order sometimes different?

Well it looks like my directory vs. file ordering is being respected, but my secondary ordering by alphabetization is... well, actually it looks like I don't do any ordering at all. Where did my ordering go? Did I abandon that?

[thombruce]

Wait, no, we use _sortBy on the DirectoryTree component (of course we do, we need to do the ordering recursively for each level).

But the logic looks correct - it should be ordering them appropriately. Digging deeper.

[thombruce]

I've fixed the incorrect folder appearing to close/open... but this doesn't correct the reordering issue.

It does look to be consistent though...

In fact it really looks as though the folders are being sorted by children length rather than just, as I'd intended, by children presence.

[thombruce]

The fix:

- return _sortBy(filtered, ['children', 'name'])
+ return _sortBy(filtered, [function(o) { return !Boolean(o.children) }, 'name'])

Although... more concise might be !o.children, right? The exclamation implicitly casts it to a boolean that is the negative of its present truthiness (a proper cast would be !!o.children).

[thombruce]

That's minimum acceptable file trashing now done! (With a last minute removal of the trash button from the root folder.)

We still want to be able to create files, which means we need a means of setting the name of the new file. I don't know if what we want for that is a modal form... I actually think it's preferable if we can set and modify the name in-place in the list. Which means an add button should create an item in the tree at the appropriate position, and that item should initially have an input field we can fill in.

Some of this may be refactored in future, we may provide options for how it's handled, we certainly want to add context menu via right click. But I think the input in-place is the clearest, most ubiquitous strategy for now.

Something for tomorrow though.

[thombruce]

Not super happy with the direction that editing file names is going, mainly because what I'm implementing right now is super broken.

I think because we're modifying values in a deeply nested store object, the props aren't being recomputed (and why should they be?) and so the values aren't reactive. This breaks subsequent edits.

I've patched the issue in a couple of places, but it's not something we want to just be patching.

The value changes should be bubbled up! That way, when the parent knows the props have changes it can better communicate this to the child components and we can respond to that appropriately.

This is fundamentally how v-model works. My brain is just fried today.

[thombruce]

Over the first hurdle: We can now edit the same file's name repeatedly.

Second hurdle:

• [x] Allow nested files to be edited after their parent directory has been renamed

At present, these nested files still point to the original name. This is a hangover from when they were mounted... so could we just forcibly rerender the entire component somehow?

[thombruce]

The big issue is... why isn't this happening automatically?

We're refetching and updating the tree value in the store. Said tree is the data which populates all of these deeply nested components... so why aren't they reflecting its state?

That's what we need to look into.

[thombruce]

Goddamn... All we needed to do was add a resolve() to the Promise. Without it, the promise was never resolving and the next steps - add toast to stack and refresh directory tree - were never happening.

It was the lack of a toast that tipped me onto this. I suddenly realised it was missing and went looking for why.

Anyway, that's renaming of files pretty much handled... except for an annoying bug where because I'm now updating a model value, the fields shift around and become unfocused when the new value is out of order alphabetically. So...

...we just need to ensure we're sorting by the existing value, and only respecting the new value fully when it is pushed through.

Then... onwards to file creation!

[thombruce]

File creation also now working.

Problem:

File is not displayed on initial creation, but is displayed after I create a second.

We're probably just missing an await.

[thombruce]

Yup, missing an await.

[thombruce]

Functionally, this is everything we wanted out of this... pretty much. Lot of room for improvement but it's a solid foundation.

It's ugly though, and we might consider restyling. Whether that is done here or left as a todo for the future, I don't know. I won't merge this just yet anyway - still needs a review.

[thombruce]

There are several issues:

• [x] We still can't create new folders, only new files
• [x] There are no validations; people can create files with any extension ...which is fine; I was thinking of Toodles when I wrote this. What we actually need is the option to supply validations.
• [ ] Styles are still lacking

[thombruce]

Whoops, this is all Toodles-specific!

We can't actually validate filename/type at the TNT level; we need some way for Toodles/other apps to communicate its file validations to the directory tree.

Speaking of extensions...

We support todo.txt, done.txt and we also lay claim to three other extensions:

• .todo
• .shop
• .list

I do wonder if that's the right thing to do - like, could we not just claim one extension instead, maybe .toodles.

It depends, doesn't it, on whether or not we want to treat the three formats any differently.

I really should document the "extension spec" and the intentions behind these three claims.

[thombruce]

We can now create new files and folders, rename or delete existing ones and... add content to them! Just tested.

It works. It's ugly but it is feature complete, except for validations.

[thombruce]

Re validations, we already do pass two useful regexes to the directory tree:

    TntElectronDirectory(
      path=""
      :extensions="/(?:\.(?:txt|todo|shop|list))$/i"
      :filter="/^(?:(?:todo|done)\.txt|.+?\.(?:todo|shop|list))$/i"
      v-slot="{ files }"
    )

The first of these is extensions and is used with the dirTree library to scan only for files with those extensions.

The second is a filter we apply after-the-fact at each level of the details/summary elements.

It's kind of redundant to pass both but... I believe both are required (I don't think the extensions regex could resemble the filter regex - I think it only checks the extension part, not the file name itself).

Regardless, that filter regex is the useful one here. Files we create should match that (folders need no validation).

[thombruce]

Validations added.

Again, it's ugly. We never set up a way to suppress error messages, so while the user is typing a hideous error will appear until the file path matches the filter regex...

...which, by the way, may not be provided? Filter is optional. I don't think I reflect that in this validation just yet.

Let's fix that, never mind that everything is hideous (change that later), and move on to review.

[thombruce]

No fix needed. If we just omit the filter, the matches: rule is left undefined and it looks as though all patterns then match the validation rules.

Onwards to review! See if there's any tidying up that can be done quickly, then get this out.