Add indicator arrow on top/bottom of viewport for drop positions outs… #2369

Zubair286 · 2024-09-05T14:51:01Z

This issue implements a feature that adds an indicator arrow on top/bottom of the viewport, if a thought is dragged over a sorted context and its drop position is outside of viewport. Checking the rank of the target position and comparing the y value of that thought with viewport height + scrollY for bottom arrow, and comparing y with scrollY for top arrow.

raineorshine

This is a good start, thanks!

You may want to address the behavioral issues below, and then we can move on to refactoring to clean up the design.

1. False negative: hovering slightly above to Colorado

There is one false negative for the bottom arrow. It doesn't show the indicator arrow even when hovering over the sorted context. Here I am hovering Colorado over the Wyoming bullet (which will drop it into the sorted States context):

2. False positive: hovering over child of sorted context

There is a false positive for both top and bottom arrows. The indicator arrow is incorrectly shown when dragging into a child of the sorted context, in which the DropHover is not outside the viewport:

The other thing to test is that it works on mobile when the keyboard is up. Unfortunately position: fixed does not work when the keyboard is up, so you'll have switch to position: absolute like in https://github.com/cybersemics/em/blob/587e1d309d9570e5ad06e9bec8eb0570867aa7d4/src/components/Tutorial/TutorialScrollUpButton.tsx.

raineorshine · 2024-09-05T16:34:21Z

src/components/Content.tsx

+  // The arbitrary space above the first thought
+  const spaceAbove = 100


This space is not arbitrary. What happens when the styles change and the space is altered? Do not treat dependent variables as independent variables. If this is dependent on the actual space above the first thought, then it needs to be functionally linked.

Sorry about this, I wanted to calculate the space relative to font size and toolbar height but left this in there accidentally.

No problem! Glad you're aware.

raineorshine · 2024-09-05T16:37:26Z

src/components/LayoutTree.tsx

+  // When a thought is hovered over a sorted context, determine the position of arrow.
+  useEffect(() => {
+    calculateThoughtPosition(treeThoughtsPositioned)
+  }, [calculateThoughtPosition, treeThoughtsPositioned])


Could you explain the trouble you had putting this in LayoutTree? It really shouldn't go in Content. Maybe we can work through the problems you encountered.

I first put it in LayoutTree but the arrow was not staying fixed relative to the viewport during scroll. So I put it in Content, I really don't like this way as well since I have to pass props to LayoutTree which really does not need to be accepting it.

It's going to have to be switched to position: absolute anyway to make it work on mobile Safari.

raineorshine · 2024-09-05T16:39:40Z

src/components/Content.tsx

@@ -47,6 +55,66 @@ const Content: FC = () => {
    return children.length
  })
  const isAbsoluteContext = useSelector(state => isAbsolute(state.rootContext))
+  const visibilityRef = useRef<'above' | 'below' | null>(null)


Refs are used to persist state across renders. Are you sure this should be a ref? It seems to me that the indicator arrow state would be completely determinable from the existing state. If it is a function of the state at one point in time, that it can be captured in a useSelector or useMemo.

I did not use state because it would cause too many renders during drag but if it can be calculated with existing state maybe I need to think about it again.

useRef and useMemo can both be used to persist state across render, but for different reasons.

useRef is used when you need different information from the last render (e.g. the previous cursor location).

useMemo is used when you need the same information from the last render (for performance optimization).

raineorshine · 2024-09-05T16:40:55Z

src/components/Content.tsx

+  const monitor = dragDropManager.getMonitor()
+
+  const item = monitor.getItem()


These should go inside the useSelector scope.

raineorshine · 2024-09-05T16:41:15Z

src/components/Content.tsx

+  const item = monitor.getItem()
+
+  const sourceThought = useSelector(state => {
+    const sourceThoughtId = head(item?.path || [])


We should probably add a check to make sure the dragged item is a Thought and not a ToolbarButton.

raineorshine · 2024-09-05T16:44:07Z

src/components/Content.tsx

+  /** Calculate the visibiltiy of thought being dragged in a sorted context.  */
+  const calculateHoverArrowPosition = useCallback(
+    (thoughts: TreeThoughtPositioned[]) => {
+      const state = store.getState()


Getting the state directly from the store is usually incorrect, as it can go stale. You need useSelector to ensure your derived values are updated when the state changes.

That's right, but I can't use useSelector inside a function so I turned to using getState method.

You would need to add useSelector outside the function, or turn the whole callback into a useSelector.

raineorshine · 2024-09-05T16:50:47Z

src/components/Content.tsx

+  /** Calculate the visibiltiy of thought being dragged in a sorted context.  */
+  const calculateHoverArrowPosition = useCallback(


How much of this can be precalculated in treeThoughtsPositioned? The purpose of treeThoughts and treeThoughtsPositioned is to have two distinct rendering phases. The first linearizes the tree, and the second calculates the x,y positions based on the size measured in the DOM. Performing additional nontrivial calculations outside these two phases adds additional complexity. It's like we're adding a third rendering phase, but it occurs in a useEffect.

linearizeTree and the useMemo that generates treeThoughtsPositioned has access to most of the state and layout information needed determine the sort position of rendered thoughts. The only thing it might not have access to is the drag-and-drop state, but you should be able to access the drag-and-drop monitor there just as easily?

Another way to put it: We are already iterating through all the tree thoughts in both linearizeTree and the useMemo that generates treeThoughtsPositioned (I really need to move that into a custom hook and give it a better name). Thus, why are we iterating through all of the tree thoughts again? It would be more efficient and less complex to perform these calculations within one of those original loops—the two phases of LayoutTree rendering.

Hope that makes sense! Let me know if I can clarify anything.

I understand the concern of reiterating the treeThoughtsPosition array, if I can put the arrow in the LayoutTree without scrolling it out of the viewport, we can use the existing state to remove the unnecessary iterations. Maybe I missed something I will try again with the arrow placement and try to find a fix for this.

raineorshine · 2024-09-05T16:52:54Z

src/components/Content.tsx

+        const currentThought = getThoughtById(state, head(path))
+        lastSortedThought = isSortedContext ? thought : null
+
+        if (isSortedContext && Math.floor(newRank) === currentThought.rank) {


Ranks are supposed to be fractional, so you should never floor them. e.g. This will break if there are thoughts with ranks 1.1, 1.2, and 1.3, because they all floor to 1.

raineorshine

All of this new logic should probably go in a custom hook as well to separate it cleanly from the rest of the component logic.

trevinhofmann · 2024-09-18T06:25:56Z

Looking good!

@Zubair286 - Have you been able to resolve this?

There is one false negative for the bottom arrow. It doesn't show the indicator arrow even when hovering over the sorted context. Here I am hovering Colorado over the Wyoming bullet (which will drop it into the sorted States context)

I am still seeing it locally during testing:

Screen.Recording.2024-09-18.at.1.23.52.AM.mov

Zubair286 · 2024-09-18T06:40:55Z

@trevinhofmann I am not sure if its a false positive but it still thinks its in States while I hover over Colorado and just below the Wyoming thought. As soon as I hover over Wyoming it shows though.

Screencast.from.09-18-2024.11.39.58.AM.webm

Zubair286 · 2024-09-18T08:45:53Z

I wonder if its because its hovering over States drop end hence it drops even when its not hovering over sorted context since that starts from Wyoming thought I believe.

Zubair286 · 2024-09-18T19:50:01Z

@raineorshine in this case where we are hovering over States drop-end, should we show the arrow? I am not sure since we are not in the sorted context yet.

raineorshine · 2024-09-18T19:56:06Z

Can you provide steps? I'm not sure what you mean.

The arrow should be shown whenever the drop target is outside the viewport.

Zubair286 · 2024-09-18T20:05:17Z

I meant like in this case, where I am hovering over Colorado but it still shows the drop target outside the viewport regardless of hover in sorted context.

Screencast.from.09-18-2024.11.34.47.AM.webm

raineorshine · 2024-09-18T20:10:09Z

Yes, this case should show the arrow. Any hover that drops into States when the sorted drop target is outside the viewport should show the arrow. The arrow needs to correspond to the drop behavior.

Zubair286 · 2024-09-18T20:33:14Z

Understood, I don't believe we have any selector that tells us that we are hovering over a drop end, since this is only because of that rest of the case are working fine.

Zubair286 · 2024-09-20T10:28:34Z

@raineorshine @trevinhofmann can you please review and confirm the functionality of this PR? Thanks

trevinhofmann

Thank you @Zubair286! The functionality all appears to work as expected when I test it locally, including the edge case I mentioned previously.

I've added a few comments, mostly related to refactoring that should be implemented to avoid polluting the <LayoutTree> with this new code which should be encapsulated elsewhere.

trevinhofmann · 2024-09-21T03:06:08Z

src/App.css

+  50% {
+    transform: translateX(-50%) translateY(10px);
+  }
+}


My understanding has been that we want to avoid adding anything to App.css in favor of completely switching to Panda for anything new, but the bobble animation here looks fine to me so long as @raineorshine is okay with this.

If you switch to Panda, here is an example of a pulse animation defined in panda.config.ts:

em/panda.config.ts

Lines 35 to 42 in 66945ae

pulse: {

from: {

opacity: 1,

},

to: {

opacity: 0.25,

},

},

I see you have already defined the arrowBobbleAnimation in panda.config.ts, so adding the animation keyframe there as well would be my preference for consistency.

Sure, I will add them in panda.config.ts

trevinhofmann · 2024-09-21T03:11:36Z

src/App.css

+
+.copy-icon-wrapper svg {
+  cursor: pointer;
+}


Were these checkbox, gift code, and copy icon styles unintentionally added? I don't see how they relate to the pull request, so I assume they were accidentally included when resolving a merge conflict (or something similar).

Yes, I believe so they got added during merge conflict during a rebase. I will remove them.

trevinhofmann · 2024-09-21T03:18:54Z

src/components/LayoutTree.tsx

@@ -449,22 +484,51 @@ const LayoutTree = () => {
    [fontSize],
  )

+  /** Compare ranks between two thoughts. */


This is a pure function and can/should be defined outside the context of the LayoutTree component (or any component).

trevinhofmann · 2024-09-21T03:22:01Z

src/components/LayoutTree.tsx

+            animation: `bobble ${token('durations.arrowBobbleAnimation')} infinite`,
+          }}
+        ></div>
+      )}


I recommend breaking this into a separate component with its own name such as <HoverArrow>. Being defined inline here without a name makes the intended functionality non-obvious to anyone skimming through the code.

src/components/LayoutTree.tsx

Zubair286 · 2024-09-23T17:06:44Z

@trevinhofmann can you review the latest code refactor changes? Thanks

trevinhofmann

The refactor looks much better, thank you!

3. False positive when dragging over toolbar or footer

@raineorshine -- I noticed one edge case. If the user drags the thought into either the toolbar or footer, the arrow is still displayed even though the thought does not get dropped into the list. Is that functioning as expected?

Demos of the edge case:

Screen.Recording.2024-09-24.at.8.23.14.AM.mov

Screen.Recording.2024-09-24.at.8.21.10.AM.mov

src/App.css

src/components/HoverArrow.tsx

trevinhofmann · 2024-09-24T12:55:41Z

src/hooks/useSortedContext.ts

+/** A hook that checks if a dragging thought is hovering over a sorted context, and returns new rank where that thought will be dropped. */
+const useSortedContext = () => {
+  const hoveringPath = useSelector(state => state.hoveringPath)
+  const contextParentPath = parentOf(hoveringPath || [])


@raineorshine - Would you agree that we should avoid || in favor of ?? for default cases like this throughout the project? I personally use the prefer-nullish-coalescing ESLint rule in my projects, because it only applies for undefined and null rather than all falsy values (such as 0), which is generally the desired behavior for default values.

@Zubair286 - This is just a comment for discussion. You don't need to make this change now, since || is already used frequently throughout the project.

trevinhofmann · 2024-09-24T13:18:35Z

src/util/compareRanks.ts

@@ -0,0 +1,23 @@
+/** Compare ranks between two thoughts. */


Is there a reason for the complexity in this function, where we convert the ranks to lists of numbers (separated by the decimal point) and compare those individually?

The function compareRanks is only used in one place to check for a negative number (compareRanks(newRank, currentRank) < 0), and it seems to return a negative number if and only if rankA < rankB. I might be misunderstanding some edge cases that this handles; can you please explain why we can't compare the ranks simply as rankA - rankB?

I was not too sure if there could be ranks like 1.1.2, 1.1.3 etc, but given the possibility I had the function written like this. It certainly can be done with just rankA - rankB, if there are not any ranks as above, please do correct me if I am wrong here.

Since the parameters are of type number, values such as 1.1.2 would not be possible.

Hmm right that was thoughtless of me, not sure why I assumed it was string, but in that case we can omit the compareRanks function and simple do newRank - currentRank and this would work just fine.

raineorshine · 2024-09-24T16:04:53Z

Good catch. The arrow should only appear when hovering over a valid drop target.

Zubair286 · 2024-09-24T17:48:38Z

The current logic depends on state.hoveringPath to figure out where we are hovering, but when hovering over toolbar/footer it gives the last hovered path, hence the arrow still shows, shouldn't it give null or a falsy value if we are not hovering over a valid drop target?

raineorshine · 2024-09-24T19:27:42Z

Yes, I think you're right. state.hoveringPath should be null or undefined when not hovering over a valid thought drop target.

Zubair286 · 2024-09-24T20:29:17Z

Right, I guess we are gonna need to update its action to return null or undefined if not hovering over valid drop targets.

Zubair286 · 2024-09-25T07:18:56Z

I see hoveringPath is being updated in useHoveringPath hook. Now, there does not seem to be anyway direct to detect if we are hovering over an invalid drop target, like I mentioned here on toolbar/footer it returns the last hovered path, so I think we can compare the previous path with current path if they are same then we can say that the drop target is not valid. Does that makes sense @raineorshine? Please correct if I am wrong about updating in useHoveringPath .

Edit: The last hovered path is only shown when hovered over toolbar, on footer it shows the path of thought that footer is covering, that is strange I think.

raineorshine · 2024-09-25T07:43:06Z

Comparing the last path with the current path doesn't really make sense to me.

It seems like the drag-and-drop monitor item should know the hover path.

Zubair286 · 2024-09-25T07:53:18Z

Yes, I can confirm it is not a viable solution.

The drag and drop monitor item has the information of the dragged item not the drop path I believe.

raineorshine · 2024-09-25T08:03:24Z

Ah, good point. I'm not sure then off the top of my head. It's going to take some investigation.

trevinhofmann

When I tested, 1-7 and 9 are all working as expected.

However, I was able to reproduce 8. False positive when canDrop is false:

Screen.Recording.2024-10-25.at.12.42.28.AM.mov

Zubair286 · 2024-10-25T06:21:46Z

@trevinhofmann its strange I can not reproduce this, I have checked logs and the hoverArrowVisibility is correctly null in this case for me.

Screencast.from.10-25-2024.11.19.17.AM.webm

Zubair286 · 2024-10-25T07:51:33Z

@trevinhofmann its strange I can not reproduce this, I have checked logs and the hoverArrowVisibility is correctly null in this case for me.

Screencast.from.10-25-2024.11.19.17.AM.webm

Nevermind this I imported the context again and it reproduced.

I have pushed the fix, can you confirm @trevinhofmann?

trevinhofmann

Thanks, @Zubair286! All of 1-9 are now working as expected for me.

raineorshine

I have tested all the cases and can confirm they all work! Amazing job.

Now just some optimization and cleanup.

raineorshine · 2024-10-26T17:37:22Z

src/hooks/useDragLeave.ts

+import useSortedContext from './useSortedContext'
+
+const DEBOUNCE_DELAY = 50
+let hoverCount = 0


I'm not sure. Generally debouncedSetHoveringPath is always called when hoverCount becomes 0 anyway, per the previous else statement, as that is the only place that hoverCount is decremented. In that case the cleanup function isn't doing anything. But if hoverCount is never incremented, then it could possibly be 0 on unmount without debouncedSetHoveringPath being called. As for what that state corresponds to or whether debouncedSetHoveringPath needs to be called then I couldn't say.

raineorshine · 2024-10-26T18:04:33Z

src/hooks/useSortedContext.ts

+  const dragDropManager = useDragDropManager()
+
+  // get the source thought and its new rank
+  const sourceThought = useSelector(state => {


It's recommended to combine everything into a single useSelector when possible. Think "thick" selector. Otherwise the render function will be called when any of the intermediate values change. We only need it to re-render when the final value changes.

raineorshine · 2024-10-26T18:20:18Z

src/components/LayoutTree.tsx

-    return { indentCursorAncestorTables, treeThoughtsPositioned }
-  }, [fontSize, sizes, singleLineHeight, treeThoughts])
+    // Determine hoverArrowVisibility based on newRank and the visible thoughts
+    if (newRank > 0 && (isSortedContext || hoveringOnDropEnd)) {


Rank is an arbitrary integer that can be negative, so the comparison with 0 is not a good idea. For example, you could have a sorted list with ranks [-3, -2, -1].

In the current codebase, when a context is sorted it may be the case that thoughts get re-ranked starting from 0, but this is tenuous and implementation-specific so we should avoid relying on that.

I can't quite figure out what purpose newRank > 0 is serving, so maybe it can be removed. Otherwise let me know what the intention is and we can find a different way to accomplish it.

raineorshine · 2024-10-26T18:23:43Z

src/hooks/useSortedContext.ts

+  return {
+    isSortedContext,
+    newRank,
+    hoveringOnDropEnd,


isSortedContext and hoveringOnDropEnd are only ever used in the expression isSortedContext || hoveringOnDropEnd. Therefore, it would be more performant and better encapsulated to move the expression into the hook, despite what might become an awkward name.

raineorshine · 2024-10-26T18:32:22Z

src/components/LayoutTree.tsx

@@ -504,6 +540,7 @@ const LayoutTree = () => {
    const tableCol1Widths = new Map<ThoughtId, number>()
    const treeThoughtsPositioned = treeThoughts.map((node, i) => {
      const next: TreeThought | undefined = treeThoughts[i + 1]
+      const state = store.getState()


We want to avoid importing the store directly. Calling getState() outside of a selector can result in a stale state.

The first render phase, linearizeTree, has access to a fresh State, we we can add rank and isSortedContext to TreeThought there and pass them down to the positioning phase.

c8a1be5 and 8192dfc

raineorshine · 2024-10-26T19:05:26Z

src/components/HoverArrow.tsx

+          height: '0',
+          borderLeft: '10px solid transparent',
+          borderRight: '10px solid transparent',
+          position: 'absolute',


Why position: absolute instead of position: fixed? It seems like position: absolute would involve a lot more manual calculation to get it in the viewport, while position: fixed does that for you.

raineorshine · 2024-10-26T19:14:26Z

src/components/LayoutTree.tsx

+      const toolbar = document.querySelector('#toolbar')
+      if (toolbar) setToolbarHeight(toolbar.getBoundingClientRect().height)
+
+      setDistanceFromTop((ref.current?.getBoundingClientRect().top ?? 0) + scrollTop)


You add scrollTop here only to subtract it below. i.e. It cancels out when you calculate maxVisibleY. Therefore, you can remove scrollTop from these calculations and avoid having to trigger useLayoutEffect on scroll.

raineorshine · 2024-10-26T19:41:39Z

Comments with commit hashes were minor issues that I fixed. I recommend taking a peek at the commits.

That just leaves two questions:

Add indicator arrow on top/bottom of viewport for drop positions outs… #2369 (comment)
Add indicator arrow on top/bottom of viewport for drop positions outs… #2369 (comment)

raineorshine requested changes Sep 5, 2024

View reviewed changes

raineorshine reviewed Sep 5, 2024

View reviewed changes

Zubair286 force-pushed the bug/1828 branch from c7835b1 to 8e5967a Compare September 16, 2024 14:14

Zubair286 force-pushed the bug/1828 branch from 8e5967a to a30fca6 Compare September 19, 2024 09:38

trevinhofmann requested changes Sep 21, 2024

View reviewed changes

trevinhofmann assigned Zubair286 Sep 21, 2024

trevinhofmann assigned trevinhofmann and unassigned Zubair286 Sep 24, 2024

trevinhofmann requested changes Sep 24, 2024

View reviewed changes

trevinhofmann assigned raineorshine and Zubair286 and unassigned trevinhofmann Sep 24, 2024

Zubair286 added 8 commits October 24, 2024 13:43

Indicator arrow implementaion in LayoutTree

67b555c

Fix edge case on showing arrow on hover sorted context parent drop end

44939c6

Refactor code from LayoutTree

9974579

remove compareRanks function

2e0b0f2

add arrow zindex to panda.config.css

fcc2a23

fix bug with arrow rendering

8b14939

fixed state.hoveringPath on toolbar/navbar and on invalid drop targets

214a3d4

updated arrow logic based on ranks of first and last visible thoughts

25c6ba9

Zubair286 force-pushed the bug/1828 branch from 176bc0a to 28a822e Compare October 24, 2024 08:52

trevinhofmann requested changes Oct 25, 2024

View reviewed changes

fix hover highlight and arrow render when canDrop is false

0ae9219

Zubair286 force-pushed the bug/1828 branch from 28a822e to 0ae9219 Compare October 25, 2024 07:49

trevinhofmann approved these changes Oct 25, 2024

View reviewed changes

trevinhofmann assigned raineorshine and unassigned Zubair286 Oct 25, 2024

Rename zIndex arrow -> hoverArrow.

18de5b1

raineorshine requested changes Oct 26, 2024

View reviewed changes

raineorshine added 9 commits October 26, 2024 19:44

HoverArrow: Convert to PandaCSS.

a3d251f

HoverArrow: Rename top and bottom props.

a47d585

Rename arrowBobbleAnimation -> verySlowPulseDuration.

25a03e3

useSortedContext: Combine into single useSelector.

853a23d

useSortedContext: Combine isSortedContext and hoveringOnDropEnd.

40a456f

LayoutTree: Add rank to TreeThought.

c8a1be5

LayoutTree: Add isSortedContext to TreeThought.

8192dfc

LayoutTree: Cancel out scrollTop.

8f4aada

LayoutTree: Rename distanceFromTop -> layoutTop.

a828e1a

raineorshine force-pushed the bug/1828 branch from 3cd0ef0 to a828e1a Compare October 26, 2024 19:46

		// The arbitrary space above the first thought
		const spaceAbove = 100

		const monitor = dragDropManager.getMonitor()

		const item = monitor.getItem()

		/** Calculate the visibiltiy of thought being dragged in a sorted context. */
		const calculateHoverArrowPosition = useCallback(

Add indicator arrow on top/bottom of viewport for drop positions outs… #2369

Are you sure you want to change the base?

Add indicator arrow on top/bottom of viewport for drop positions outs… #2369

Conversation

Zubair286 commented Sep 5, 2024 • edited by trevinhofmann Loading

raineorshine left a comment • edited Loading

Choose a reason for hiding this comment

1. False negative: hovering slightly above to Colorado

2. False positive: hovering over child of sorted context

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raineorshine Sep 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raineorshine Sep 5, 2024 • edited Loading

Choose a reason for hiding this comment

raineorshine left a comment

Choose a reason for hiding this comment

trevinhofmann commented Sep 18, 2024

Zubair286 commented Sep 18, 2024 • edited Loading

Zubair286 commented Sep 18, 2024 • edited Loading

Zubair286 commented Sep 18, 2024 • edited Loading

raineorshine commented Sep 18, 2024

Zubair286 commented Sep 18, 2024

raineorshine commented Sep 18, 2024

Zubair286 commented Sep 18, 2024

Zubair286 commented Sep 20, 2024 • edited Loading

trevinhofmann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trevinhofmann Sep 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Zubair286 commented Sep 23, 2024

trevinhofmann left a comment • edited by raineorshine Loading

Choose a reason for hiding this comment

3. False positive when dragging over toolbar or footer

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Zubair286 Sep 24, 2024 • edited Loading

Choose a reason for hiding this comment

raineorshine commented Sep 24, 2024

Zubair286 commented Sep 24, 2024 • edited Loading

raineorshine commented Sep 24, 2024

Zubair286 commented Sep 24, 2024

Zubair286 commented Sep 25, 2024 • edited Loading

raineorshine commented Sep 25, 2024

Zubair286 commented Sep 25, 2024 • edited Loading

raineorshine commented Sep 25, 2024

trevinhofmann left a comment

Choose a reason for hiding this comment

Zubair286 commented Oct 25, 2024 • edited Loading

Zubair286 commented Oct 25, 2024

trevinhofmann left a comment

Choose a reason for hiding this comment

raineorshine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raineorshine Oct 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Zubair286 commented Sep 5, 2024 •

edited by trevinhofmann

Loading

raineorshine left a comment •

edited

Loading

raineorshine Sep 5, 2024 •

edited

Loading

raineorshine Sep 5, 2024 •

edited

Loading

Zubair286 commented Sep 18, 2024 •

edited

Loading

Zubair286 commented Sep 18, 2024 •

edited

Loading

Zubair286 commented Sep 18, 2024 •

edited

Loading

Zubair286 commented Sep 20, 2024 •

edited

Loading

trevinhofmann Sep 21, 2024 •

edited

Loading

trevinhofmann left a comment •

edited by raineorshine

Loading

Zubair286 Sep 24, 2024 •

edited

Loading

Zubair286 commented Sep 24, 2024 •

edited

Loading

Zubair286 commented Sep 25, 2024 •

edited

Loading

Zubair286 commented Sep 25, 2024 •

edited

Loading

Zubair286 commented Oct 25, 2024 •

edited

Loading

raineorshine Oct 26, 2024 •

edited

Loading

raineorshine Oct 26, 2024 •

edited

Loading

raineorshine Oct 26, 2024 •

edited

Loading

raineorshine Oct 26, 2024 •

edited

Loading

raineorshine Oct 26, 2024 •

edited

Loading

raineorshine commented Oct 26, 2024 •

edited

Loading