refactor(components): ♻️ match styles for Drag n Drop handles

[lloydrichards]

In order to be consistent I would add the arrows to the drag & drop handels in the table chart as well, as we have it for the cascading filters.

#362

---

Goals/Scope

The initial issue was just the match the visual styles of the Table Column (table-chart-configurator.tsx) and Filter (chart-configurator.tsx) sorting via drag and drop. The filters have small arrows that allow you to increment the filters up or down. Refactoring the MoveDragButtons components do it can be shared between the Draggable components.

Description

Initial I wanted to be able to include the functionality of the up and down arrows into the Table Columns, but it seems like the logic between the two areas is quite different when calculating the new config. Refactoring the MoveDragButtons component involved pulling out the onUp and onDown logic, but in the Table Columns this

Comments

I'm not a fan of how the structure differs between table-chart-configurator.tsx and chart-configurator.tsx in how the ordering is handled or the reliance on array mutation in the moveField() (table-config-state.tsx). At the risk of opening up a larger refactor, i'm noting here that there is legacy separations in both coding styles and structure in these areas of code

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
visualization-tool	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 10, 2023 3:28pm

[bprusinowski]

Nice, I think you started in the right direction @lloydrichards!

I think you should be able to use onDragEnd callback in the onUp and onDown, you just would need to create source on the fly (I think it should be possible, as it consists of droppableId, which you should have access to ("groups" and "columns"), and you can access index via onUp / onDown callback).

As the onDragEnd / onDragStart logic differs a lot between table and regular configurators, I am not sure if it makes a lot of sense to try to consolidate them. Maybe just the last dispatch (CHART_CONFIG_REPLACED)?

Also not sure how much we can actually share between drag & drop components / logic for filters and table, as it looks they have mostly different structures (e.g. one has section title and section content, the other one not). Maybe in fact the filters should also have the section title and content wrappers inside them – in this case, we could extract something like SidebarDragDropWrapper? But I think this would need to be cross-validated with the design, to see if it makes sense :)

Let me know what you think, and if you had some other approach in mind 👀

[lloydrichards]

Ive tried a few time to untie some of the logic between the table-config-state.tsx and make things more clear on how the reordering is working, but it eludes me at the moment. Trying to replicate the moveFields() to be able to take an index and delta is lacking some deeper understanding on how these mutations are happening and not a way of programming im comfortable with.

For now if the idea is to just add the visual design of the arrows to match between filters and columns, then the current PR will work and the onUp and onDown props can be left empty. Not a very satisfying conclusion, but easier then going down the rabbit hole of manipulating the order logic without understanding the consequences 🤷‍♂️

[bprusinowski]

LGTM 👏

[bprusinowski]

💯