OK I added a bunch of improvements to other areas adjacent to what we were doing using your method -- can you check my work?

Thanks Aaron -- wow, amazing useEffect routine now. But it may be too much?

The original intent of issue #334 was to scroll to a newly added widget, not one that moved. The problem being solved was that when a new widget is added, it's added at the bottom, which means the user has to search for it to move it. Once the user is moving it, they know where it moved to, no need to scrollTo and draw attention to it with animation. With the scroll-after-moving and animation, it's feels jarring, to me.

Or is there another use case that you've solved? Maybe I don't understand the changes made.

BTW, I LOVE the flash effect, that was what I was wanting but found the animate-bounce was built-in with tailwind. I wish the animate-ping was better suited.

The original intent of issue #334 was to scroll to a newly added widget, not one that moved. The problem being solved was that when a new widget is added, it's added at the bottom, which means the user has to search for it to move it. Once the user is moving it, they know where it moved to, no need to scrollTo and draw attention to it with animation. With the scroll-after-moving and animation, it's feels jarring, to me.

All fair and completely makes sense. Here's what I experienced when I first pulled:

If I created something new from the AllView it took me to the bottom and there was a beautiful animation - as expected! Looked and felt really nice. I immediately went to try to create a new view inside of a container, but when that succeeded -- it scrolled me to the bottom of ContextMenu. This was a confusing experience, because the item appeared somewhere up above. So instead of just letting you knwo about that I fixed it. Then I fixed something else. Then I was tweaking the styles of buttons and so on, and definitely got carried away, but here are the main use cases I'm accommodating:

• Scrolling to the active item on load
• Scrolling to any new item, regardless of it's provenance (whether created via contextmenu or allview)

Among other many style improvements.

The fact that this happens when something is moved is an accident, and I'll fix that -- you're totally right. And in the future I'll just leave a comment and move on, but I loved what you did so much I just couldn't help myself... sorry if I stepped on your toes!

Yeah this is a mess. I had it working yesterday afternoon but I made some changes that were rushed and messy at the end and didn't thoroughly check my work, I'll clean this up!

OK I talked to Kevin and he's going to roll back my changes, I'll incorporate the good ones elsewhere and leave the pain and sorrow of failure behind

Kevin here's how to reproduce the experience I fixed initially before I just started fixing everything like a bull in a china shop

When doing my first pass on editing of the context menu, I created probably 50 views and containers and so on in a specific group. It's got every case and combination so that I can test everything at the same time.

If I go into that group, and click on the "Edit Menu" button, the context menu changes (more elements added) so that what I just clicked on scrolls out of view, and the AlllView.jsx appears in the main column.

If I click on "Add view" and create a new container, the contextMenu scrolls to the bottom and the new item appears, bouncing nicely. This is all great!

Now if I drag the container I just created up the list to the middle of many items, and click the "Add new view" button inside the container, and create a chat -- the contextMenu scrolls to the bottom but nothing appears. Nothing appears because the element gets created within the container I dragged up past the viewport.

I think we either should have no animation in the case I just mentioned (because clicking that button means that the element will almost always render within the viewport, because it renders right next to the button someone just pressed) or always animate to newly created context menu items, regardless of where they were created. I went the latter route, but the former is likely easier.

Another change I added once all that was working was scrolling to the current item, which was easy to add once the rest of that stuff was figured out. I don't think this needs to be done for this release, but whatever you build will be good infrastructure for this.

No problem, Aaron, thanks for pitching in and excellent recovery!

If I go into that group, and click on the "Edit Menu" button, the context menu changes (more elements added) so that what I just clicked on scrolls out of view, and the AlllView.jsx appears in the main column.

Great point -- I'll fix the Context Menu changing when clicking the Edit Menu button.

If I click on "Add view" and create a new container, the contextMenu scrolls to the bottom and the new item appears, bouncing nicely. This is all great!

Great! Keep this ;-)

Now if I drag the container I just created up the list to the middle of many items, and click the "Add new view" button inside the container, and create a chat -- the contextMenu scrolls to the bottom but nothing appears. Nothing appears because the element gets created within the container I dragged up past the viewport.

Ah! I didn't know about this method for adding views! So views and widgets. That makes total sense. I'll fix this.

I think we either should have no animation in the case I just mentioned (because clicking that button means that the element will almost always render within the viewport, because it renders right next to the button someone just pressed) or always animate to newly created context menu items, regardless of where they were created. I went the latter route, but the former is likely easier.

Right! I think let's do nothing, no animation and no scrolling (well, maybe that cool border animation you made) since the new view shows up where expected. I'll add lots of views and see how it works.

I'll ping you once it's done for your review with your mondo-view test group!