Scroll up/down when dragging grid event

[tyler-dane]

Feature Title

Smart Scroll During Drag

Feature Description

The dragging a timed event up or down outside of the current view, the draft is no longer seen. Instead, we should automatically scroll so that the draft is always visible

Use Case

This'll make users more comfortable dragging events, because they'll always be able to see them

Additional Context

This will likely require some logic to identify if the current mouse position is in the current view port. If not, scroll upwards/downwards until it is

[tyler-dane]

Hey @that-one-arab , heads up that that I'm working on refactoring how drafts are created and updated in #255, which may result in conflicts with your implementation here. I'm trying to keep the changes contained to minimize that scenario.

Normally I'd encourage you to refactor surrounding code as you do your implementations in an effort to always leave the code more clean and maintainable, but since our cleanups might differ, in this case you don't need to do that. Instead, feel free to share suggestions on how to change related code in the comments of #255

[that-one-arab]

@tyler-dane Hey, I am working on this issue and I think I reached a point where I am probably blocked from working on it.

In 262 useDragEventSmartScroll:16 I have if (!draftEvent) return;

This will be corrected to something like if (draftEvent.status !== 'dragging') return; but regardless, I need to know the type of action being performed on the draft event (resizing, dragging, or simply editing)

Right now this isn't possible to do using redux selector, because in MainGridEvents:49 we always dispatch draftSlice.actions.startDragging regardless of whether we are actually dragging the event, which sets the event status to dragging.

So I would either need to do something really ugly (like passing useDraftUtil:draftState around to get the state from this object, or somehow refactor the current implementation to allow me to get the draft event status from redux store.

But since you already warned me that you are doing large refactors with how draft events work (I also noticed your draft PR here #255 I am unsure on how to proceed

Please advise.

[tyler-dane]

Hey @that-one-arab , thanks for the heads up about being blocked.

It sounds like the core issue is that in order to implement this feature correctly, you need to be able to distinguish when the user is actively dragging an event (has his mouse down on an event) and when they are simply editing an event (resizing or looking at an open form).

#255 just got merged, which I think will make working with this easier. However, the core issue will still be there.

I share your hesitancy to do something really ugly.

I suggest merging main and seeing if there's a simple way the fix the core issue, perhaps by using the new Activity_DraftEvent type that came from #255.

If not, then consider stepping away from this feature and focusing on the core issue. You could takeover #229, which would require a solution that would also fix this core issue. (That issue is assigned to me but I haven't done any work on it)

[that-one-arab]

@tyler-dane If I were to try to see if a simple solution exists (using your suggested Activity_DraftEvent) or fixing the core issue, I would need to pull your changes from #255

But since the PR is still draft and still a WIP, I suggest we finalize the PR first then do either of the above mentioned approaches, that way I always have up-to-date changes.

So, if you agree to my suggestion, I can either work on an issue that is unrelated to draft events and won't block me, or I can pick up #255 myself and finalize it, then work on the respective related issues (this and #229)

Please advise.

[tyler-dane]

"I can pick up #225 myself and finalize it"
#255 is merged, so you wouldn't pick it up and finalize it. It's done.

" I would need to pull your change [...]"
Yes, pulling in the latest changes from main, including those from #255, is a good first step.

You will need to either pull in changes from main (including those from #255) into this branch or cherry-pick your changes from this branch onto a new one that is branched off main.

So, you're not blocked (right?). You just need to decide whether you want to continue on this issue or pause to finish #229 and then come back to this one.

[that-one-arab]

@tyler-dane Ah my bad I did not notice it was merged. Yes. I am not blocked at the moment and will continue work on this. I don't understand the benefits of choosing #229 to pick up and finish first since in both cases I may need to address the core issue of the way draft events redux store selection is handled, so I will opt to continue work on this PR.