extensions refactor POC #46
Conversation
❌ Deploy Preview for jstodotxt failed.
|
|
Hi @benjamonnguyen . I havn't looked into your proposal here I can't really tell, what it is doing. But over at sleek (https://github.com/ransome1/sleek) I have some trouble implementing individual extensions, since the switch to the We have a use case in sleek, where we need to detect speaking dates for Due and Threshold. Currently In the Is you proposal here capable of tackling a use case like this one? |
|
@ransome1 The todo.txt spec doesn't support whitespace for extensions. https://github.com/todotxt/todo.txt#additional-file-format-definitions
I'd recommend going with something like TxDx's solution. If you were to pursue this format, maybe you can create a class that extends the jstodotxt/Item class and override the setBody() method to add your custom parsing logic. This PR is trying to address the way tag positions are tracked using spans which in my experience seems to be more error prone and complicated. |
This is my proposal to refactor the extension system (and tags as a whole):
I've found this way of handling and working with extensions to be a much easier developer experience that maintains the desired flexibility with the extension system.
It also resolves issue 45.
Rather than tracking spans, the body is treated as a space delimited string array and an array of indices is maintained for each tag to replace the current tracking logic.
If you'd like to pursue this implementation, I can implement the same pattern for projects/contexts and add tests.