We didn't have time to introduce redux into dragAndDrop from the beginning of the fork so we pushed forward with current architecture of dragAndDrop plugin. In order to clean-up current codebase and simplify data flow, we will need to integrate redux into the plugin. This effort will result in refactoring most of dragAndDrop.
*1 During vertical/horizontal reorder there are a few props that are updated by dragAndDrop plugin: start, end, weight. But due to not having enough time to properly track and store changes, we mutate the original object in place. The ideal solution is to store the new props internally and once we call onEventReorder we pass to the user the following: list-of-original-events-that-were-reordered, props-that-need-to-by-updated, contains-a-new-event <- outsideEvent type... is important to the user, since he might need to take a different action if the reordered list contains a new event or not.
We didn't have time to introduce redux into
dragAndDropfrom the beginning of the fork so we pushed forward with current architecture ofdragAndDropplugin. In order to clean-up current codebase and simplify data flow, we will need to integrate redux into the plugin. This effort will result in refactoring most ofdragAndDrop.dragAndDrop*1*1During vertical/horizontal reorder there are a few props that are updated bydragAndDropplugin:start,end,weight. But due to not having enough time to properly track and store changes, we mutate the original object in place. The ideal solution is to store the new props internally and once we callonEventReorderwe pass to the user the following:list-of-original-events-that-were-reordered,props-that-need-to-by-updated,contains-a-new-event<- outsideEvent type... is important to the user, since he might need to take a different action if the reordered list contains a new event or not.