Reordering Tasks in Focus Doesn't Always Work

[mt-xing]

Around 90% of the time, reordering a task in focus view by clicking and dragging just results in the task snapping immediately back to where it was. It'll take about a dozen tries before the task actually stays where it was dropped.

[SamChou19815]

There is an easy way to reproduce this:

1. Setup two tasks in the focus view
2. Try to drag the first task to the bottom of the task view.
3. The task will bounce back.

A potential solution is to make the droppable section bigger.

[SamChou19815]

Setting the droppable's css to be height: 100% seems to fix the problem I mentioned above. (A potential fix is in the #158 branch) @mt-xing can you confirm whether it's the only problem?

[mt-xing]

That's strange. I've been entirely unable to reproduce the bug at all in either of our development branches - neither master nor the experimental typescript branch. It's very prevalent on samwise.today though. Here's a video: https://youtu.be/UrPOpAIC8Ig

[SamChou19815]

That's strange. I've been entirely unable to reproduce the bug at all in either of our development branches - neither master nor the experimental typescript branch. It's very prevalent on samwise.today though. Here's a video: https://youtu.be/UrPOpAIC8Ig

@mt-xing I was unable to reproduce the problem on my machine. But I do notice that there will be a little trouble to drag and drop when the focus view's visible parts cannot show 2 tasks.

[SamChou19815]

I believe I understand the root cause.
Suppose we have T1 (focused), T2 (not focused), T3 (focused) in this order.
Current implementation will pass all the tasks to the focus view, and the a task component inside the focus view decides whether to render or return null.
Therefore, this kind of virtual DOM may be rendered:

return (
  <div>
    <FocusedTask key="1" />
    {null}
    <FocusedTask key="3" />
  </div>
);

This solution may work for any other circumstances, but not for drag-and-drop, at least for the current framework, because the presence of null inside the virtual DOM may affect the drop position calculation. I'm going to fix this when I'm implementing the separation of completed task and uncompleted task in focus view.