Closed thombruce closed 1 year ago
github-actions[bot]
commented
1 year ago | Status | Category | Percentage | Covered / Total |
|---|---|---|---|
| 🟢 | Lines | 83.11% / 60% | 379 / 456 |
| 🟢 | Statements | 83.11% / 60% | 379 / 456 |
| 🟢 | Functions | 64.7% / 60% | 33 / 51 |
| 🟢 | Branches | 79.68% / 60% | 51 / 64 |
thombruce
commented
1 year ago Perhaps the parsed value need not be removed, only stylised similar to projects/contexts/tags. The only problem with this is... what of the creation date? Sure, we can intelligently insert it after the priority in output, but we would prefer the simpler approach of concatenating strings.
With that in mind, an approach that combines the above two todos into one:
([A-Z])To achieve this, we'll add a getter for the editable value. Call it... get editable() {}. Then we swap out the contenteditable value for this whenever it is chosen for editing?
Maybe.
thombruce
commented
1 year ago Problem: At present when I edit a Todo, the new priority is parsed and set on the todo appropriately. However, the string does not update. Why? Because the string is a v-model instance of the todo.text, and the todo is taken directly from list.data in the state; these are not cast to the Todo class. However... the value in the list should still be updating. Hmm...
For some reason todo.name is not reactive. Will look at that a bit more...
thombruce
commented
1 year ago Todos themselves are certainly reactive. All other elements updating appropriately. I have to assume Todo.name is also, but the contentEditable area is simply not updated after a change... Why should that be the case?
thombruce
commented
1 year ago Oddly enough, if I add any tags it does work and updates the contenteditable area appropriately. It is only when I try to add/update the priority itself this is not working...
thombruce
commented
1 year ago Here's the issue: If I update the priority, todo.name is not changing. This is why the component isn't refreshing.
We could fix this by parsing out the priority at the component level rather than the model... and updating the text there to suit. Don't love this.
Have attempted a $forceUpdate hack on the update method, but this doesn't appear to resolve the problem.
Did attempt to use todo.name as key earlier, but of course this didn't work because name wasn't updated, as I now realise.
In fact, neither of those ideas is truly ideal. We would still prefer that the contenteditable area showed a sort of "raw" text when editing, and a "pretty" name when displaying...
Consider... storing the raw text of the input?
Alternatively, we would have to reconstitute it from the priority and name parts.
Also be aware, I've been filtering out priority with the idea that it is more sortable separately... but it's not really. Since parentheses precede all alphanumeric characters alphabetically, we can just sort the raw text by priority with alphabetical sorting:
['b', 'a', 'Z', '9', '22', '0', ')', '('].sort()
// ['(', ')', '0', '22', '9', 'Z', 'a', 'b']All of the above being to say, let's actually do for priority what we did for tags. Make it writeable/editable directly from the todo input, and apply pretty styling via regex utilisation at display time.
Remember, keep it simple. When the simplest solution is implemented and working, then consider gradual enhancements over time.
thombruce
commented
1 year ago Sortability where priority is part of the string but date is not leaves a significant amount to be desired...
Would prefer to sort by priority (rather than alphabetical content of raw attribute) AND THEN created date.
Short of also including the created date in the raw value for all todos... I'll have to come up with some other idea.
thombruce
commented
1 year ago Extracting and storing the priority separately was part of my earlier efforts. It isn't really redundant to do both now... For one, better indexing while maintaining a cached raw value to be output to todo.txt later.
We... might always maintain a raw value? And perhaps created date should be a part of that if it was created within our system or was otherwise present anyway.
That being the case... we do again need an editable value apart from the raw data, since we do not wish to display dates at present. Certainly not as part of the editable string - it's already a bit of a stretch to be handling priority this way, but it is nice to be able to do so.
thombruce
commented
1 year ago With that being the case, I am considering merging this and creating a separate issue to handle...
I guess we should lay down some prep here for item three.
thombruce
commented
1 year ago There's extra notes on #71 about how I want to handle things going forwards. The raw attribute I've just created/renamed... probably gets replaces with priority and description. I should do that here.
We just then also need to be able to concatenate these into an editable string from which the parts are parsed out of the form (${priority}) ${description}.
thombruce
commented
1 year ago Gonna merge and handle the proposed changes on #71
closes #68