feat: automatically create subtask relations based on indention #2443
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2443
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/subtask-via-indention"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR adds the automatic creation of subtasks via indention.
For example, creating tasks with this multiline input:
will make
sub task one
andsub task two
a sub task ofparent task
andsub task three
a sub task ofsub task two
.Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2443-feature-subtask-via-indention--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
@ -165,1 +164,3 @@
if (title === '') {
const createdTasks: ITask[] = []
const tasksToCreate = parseSubtasksViaIndention(newTaskTitle.value)
const newTasks = tasksToCreate.map(async t => {
spread title:
({title}) => {
@ -181,0 +185,4 @@
const relations = tasksToCreate.map(async t => {
const createdTask = createdTasks.find(ct => ct.title === t.title)
if (t.parent === null) {
emit('taskAdded', createdTask)
In line 194 we return if
typeof createdTask === 'undefined'
.This implies that createdTask could be undefined here aswell. Is that intended?
mhh I didn't think this through. It should never be null.
I've adjusted this so that there's a check before emitting it.
@ -0,0 +1,42 @@
export interface TaskWithParent {
Why do we create a new interface for this and don't use ITask for this?
Because this is only used to hold the title and parent title. Using
ITask
would probably work but I felt it would introduce too much overhead for a simple relation.Unsure: would it make sense to create the new type still on
ITask
with the help ofPick
, like:I think explicitely declaring it is more readable.
Good with me. I still think we should reuse the types from the task interface. Meaning:
The reason beeing here: In the medium term we should change the id in the frontend to a string to make indexing easier. Because objects don't support number types as keys. The alternative would beto use Maps everywhere which is unrealistic (because they do support numbers as keys). By using zod this shouldn't be too complex.
But we're not even using IDs here, only string titles.
Arrrrgh… makes sense. Sry i missed that part :D
@ -0,0 +14,4 @@
export function parseSubtasksViaIndention(taskTitles: string): TaskWithParent[] {
const titles = taskTitles.split(/[\r\n]+/)
return titles.map((t, i) => {
Picky: use clear variable name, e.g.
title
,index
.Makes reading easier since you don't have to remember and jump to the var definition.
Makes sense. Done!
@ -0,0 +20,4 @@
parent: null,
}
const matched = spaceRegex.exec(t)
Move
matched
andmatchedSpaces
in condition aswell since it's not used forindex === 0
Added an earlier break for
index === 0
.c5f4f22923
to65b1d9abc5
@ -0,0 +9,4 @@
const spaceRegex = /^ */
// taskTitles should be multiple lines of task tiles with indention to declare their parent/subtask
Idea: use JSDoc to explain param
Check if any comments make sense, else ready to merge 👍
4a05db20f8
to5bd7c77b68