bakkerjoeri / dust-bunnies Goto Github PK

When you add a task to the Today view it can take a little time to show up. More precisely it shows up whenever the time store gets a new value. The task should instead show up immediately.

I think the problem exists in the comparison of the deferredTo timestamp and the now timestamp in isTaskForToday:

• When you set the update interval of time to 10000 it takes upwards of 10 seconds for a newly created task to show up.
• If you immediately return true from isTaskForToday the problem goes away.

When a modal is open the content behind it can scroll which leads to weird behavior on mobile. Content behind the modal shouldn’t scroll. Make sure that when the modal opens, scroll height of the content behind it is retained.

Generally, only links should show a pointer cursor, while buttons and other interactive elements should not. This is the default behaviour for a reason. Remove cursor: pointer from labels and buttons.

Steps to reproduce:

1. Create a task with a subtask
2. Try to click on the subtask's checkbox to complete it

Expected result:
The task is completed and the checkbox becomes checked to reflect that.

What actually happens:
The task is completed (the data reflects this change) but the checkbox doesn't change its checked state.

Show existing tags sorted by usage below the tag input field. When a tag is tapped, add it to the set of selected tags. Filter the set while typing a new tag.

The tasks in something like tasksForToday don't change without refreshing when the day changes. This is because the value of now is calculated once and doesn't change when update, so there is no dependency on an updating now timestamp.

Introduce a store with an updating now so other filtered sets can depend on its value.

When opening a modal focus should be trapped and loop so the user doesn't tab through inaccessible items behind the modal.

When logging in on a new device, rootTaskIds holds a value of []. This value is synced to firebase regardless of what was there serverside and causes people to lose their tasks. The data still exists but is not displayed.

Possible solutions:

• Add some callback to firestoreUserDocumentField that determines what happens to the data on login. Use it to merge the local data with the serverside data.
• Remove the data altogether and derive roottasks rather than storing them. They are tasks that don't exist in any other task's subTaskIds property. This could be a performance hit however.

When adding a subtask, the following happens:

1. The subtask is created, altering the task collection and triggering an update
2. The subtask is added to the parent task, again altering the task collection and triggering an update
3. Snapshot from the update in step 1 arrives clientside and changes from step 2 locally become undone, triggering an update.
4. Snapshot from the update in step 2 arrives clientside and changes from step 2 are reimplemented, triggering an update.
5. Infinite recursion

Possible solutions:

• Look into working with transactions to prevent race conditions.
• Figure out which differences are outdated and shouldn't change clientside state.
• Update the tasks in a single change and use transactions in the firestore handlers to push all collection changes to the server.

Steps to reproduce:

1. Create a task
2. Set the defer date to something, save
3. Set the defer type to "don't defer" and set a due date, save

The task should now show up in the "upcoming" overview under that defer date.

When a task is deleted its subtasks remain in the store. They should be deleted as well.

User story

As a person who uses the task app at work I would like to filter by the tag "work" and be able to add tasks to it easily so that I don't have to repeat myself all day

Requirements

• Apply the currently filtered tag when creating a task through "add here"

Support for dialog element has reached the big browsers, so it's time to implement it.