Decoupling data table manager components

[ddouglasz]

We want to be able to consume the data table settings in the data table without having so much restrictions to how they are currently structured in the DOM tree.
We want to decouple the DataTableManager such that the settings dropdown component can live anywhere in the DOM tree from the DataTable
The current way it works is one in which the Datatable is always directly after the Datatable settings dropdown.
The settings dropdown should be flexible to exist anywhere in the component that it is used.

This PR implements this feature using the Provider method, where the provider allows both the data table settings dropdown and the datatable to share state from a common source, allowing us the flexibility we want.

An alternative approach is to managing the state using a Window method as seen in this POC. But this posed to have some complexities regarding how to manage the initial states and also the security implications of storing the state in a global window object

An example of where this can be useful:

[changeset-bot]

🦋 Changeset detected

Latest commit: 1af83b5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 96 packages

Name	Type
@commercetools-uikit/data-table-manager	Minor
@commercetools-uikit/data-table	Minor
@commercetools-frontend/ui-kit	Minor
@commercetools-uikit/design-system	Minor
@commercetools-uikit/calendar-time-utils	Minor
@commercetools-uikit/calendar-utils	Minor
@commercetools-uikit/hooks	Minor
@commercetools-uikit/i18n	Minor
@commercetools-uikit/localized-utils	Minor
@commercetools-uikit/utils	Minor
@commercetools-uikit/accessible-hidden	Minor
@commercetools-uikit/avatar	Minor
@commercetools-uikit/card	Minor
@commercetools-uikit/collapsible-motion	Minor
@commercetools-uikit/collapsible-panel	Minor
@commercetools-uikit/collapsible	Minor
@commercetools-uikit/constraints	Minor
@commercetools-uikit/field-errors	Minor
@commercetools-uikit/field-label	Minor
@commercetools-uikit/field-warnings	Minor
@commercetools-uikit/grid	Minor
@commercetools-uikit/icons	Minor
@commercetools-uikit/label	Minor
@commercetools-uikit/link	Minor
@commercetools-uikit/loading-spinner	Minor
@commercetools-uikit/messages	Minor
@commercetools-uikit/notifications	Minor
@commercetools-uikit/pagination	Minor
@commercetools-uikit/primary-action-dropdown	Minor
@commercetools-uikit/progress-bar	Minor
@commercetools-uikit/stamp	Minor
@commercetools-uikit/tag	Minor
@commercetools-uikit/text	Minor
@commercetools-uikit/tooltip	Minor
@commercetools-uikit/view-switcher	Minor
@commercetools-uikit/accessible-button	Minor
@commercetools-uikit/flat-button	Minor
@commercetools-uikit/icon-button	Minor
@commercetools-uikit/link-button	Minor
@commercetools-uikit/primary-button	Minor
@commercetools-uikit/secondary-button	Minor
@commercetools-uikit/secondary-icon-button	Minor
@commercetools-uikit/dropdown-menu	Minor
@commercetools-uikit/async-creatable-select-field	Minor
@commercetools-uikit/async-select-field	Minor
@commercetools-uikit/creatable-select-field	Minor
@commercetools-uikit/date-field	Minor
@commercetools-uikit/date-range-field	Minor
@commercetools-uikit/date-time-field	Minor
@commercetools-uikit/localized-multiline-text-field	Minor
@commercetools-uikit/localized-text-field	Minor
@commercetools-uikit/money-field	Minor
@commercetools-uikit/multiline-text-field	Minor
@commercetools-uikit/number-field	Minor
@commercetools-uikit/password-field	Minor
@commercetools-uikit/radio-field	Minor
@commercetools-uikit/search-select-field	Minor
@commercetools-uikit/select-field	Minor
@commercetools-uikit/text-field	Minor
@commercetools-uikit/time-field	Minor
@commercetools-uikit/async-creatable-select-input	Minor
@commercetools-uikit/async-select-input	Minor
@commercetools-uikit/checkbox-input	Minor
@commercetools-uikit/creatable-select-input	Minor
@commercetools-uikit/date-input	Minor
@commercetools-uikit/date-range-input	Minor
@commercetools-uikit/date-time-input	Minor
@commercetools-uikit/input-utils	Minor
@commercetools-uikit/localized-money-input	Minor
@commercetools-uikit/localized-multiline-text-input	Minor
@commercetools-uikit/localized-rich-text-input	Minor
@commercetools-uikit/localized-text-input	Minor
@commercetools-uikit/money-input	Minor
@commercetools-uikit/multiline-text-input	Minor
@commercetools-uikit/number-input	Minor
@commercetools-uikit/password-input	Minor
@commercetools-uikit/radio-input	Minor
@commercetools-uikit/rich-text-input	Minor
@commercetools-uikit/rich-text-utils	Minor
@commercetools-uikit/search-select-input	Minor
@commercetools-uikit/search-text-input	Minor
@commercetools-uikit/select-input	Minor
@commercetools-uikit/select-utils	Minor
@commercetools-uikit/selectable-search-input	Minor
@commercetools-uikit/text-input	Minor
@commercetools-uikit/time-input	Minor
@commercetools-uikit/toggle-input	Minor
@commercetools-uikit/spacings-inline	Minor
@commercetools-uikit/spacings-inset-squish	Minor
@commercetools-uikit/spacings-inset	Minor
@commercetools-uikit/spacings-stack	Minor
@commercetools-uikit/buttons	Minor
@commercetools-uikit/fields	Minor
@commercetools-uikit/inputs	Minor
@commercetools-uikit/spacings	Minor
visual-testing-app	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
ui-kit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 17, 2024 10:50am

[ddouglasz]

After comparing both options, I would go with this option since it does not seem to require the user importing a new Provider or any other form of import.
But I am also interested in knowing what @commercetools/shield-team-design-system think about this.

[ddouglasz]

if we use this alternative, we would miss the initial state. and it seems to me like we simply just need to pass the columns object just the same way it was used in the data-table-manager. Current solution works well, as expected.

Suggested change

	const columns =
	const [columns, setColumns] = useState<[]>();
	const handleCustomEvent = (event) => {
	const { columns } = event.detail;
	setColumns(columns);
	};
	useEffect(() => {
	window.addEventListener(‘DataTaBleManagerEvent’, handleCustomEvent);
	return () => {
	window.removeEventListener(‘DataTaBleManagerEvent’, handleCustomEvent);
	};
	}, []);

[ddouglasz]

I would use the window.dispatch but it seems like we would be missing the initial state using this approach

Suggested change

	window.dataTableColumns = { columns };
	useEffect(()=> {
	const customEvent = new CustomEvent(‘DataTaBleManagerEvent’, {
	detail: {columns}
	})
	window.dispatchEvent(customEvent)
	},[columns])

[CarlosCortizasCT]

Yes, if we go for the events approach, it will be difficult to get the initial state as the DataTable component can be rendered after the DataTableManager would have sent the initial state event and that will imply having some kind of event bus where a consumer can consume past events but that means maybe too much complexity.

On the other hand, using the window object to communicate data using new properties is risky because of global space pollution.
We would need to be very careful because other libraries we don't know our consumers could be using might use the same attribute name and break things.
Also, it can be also challenging managing the cleanup of that global state.

I believe the provider approach might be a safer one.
We will be supporting both use cases: DataTable as a children of the DataTableManager
(which won't require the provider) and the DataTable detached (which will require the provider).
In the second use case, the state have to be lifted to a common parent anyway: it's a matter of leaving that state management up to the consumers or providing some help from our side, which I think the new provider would do well.

So, all in all, I think the provider approach will benefit us in the long term.

[ddouglasz]

Thank you for the comprehensive feedback. I will push a change with the Provider approach since it is now clear that we would have some security/complexity concerns using the window approach 🙏🏾

[ddouglasz]

updated here: 39a97a4

Thank you.

[chloe0592]

Thanks @ddouglasz for working on it, this was a tricky one.

[ddouglasz]

We also want to be sure that when the datatable manager is decoupled, all it's behaviours are still intact.

[CarlosCortizasCT]

Thanks a lot for all your work in this PR, Douglas! 🙇

[CarlosCortizasCT]

It would be great to include a breaking line between the two paragraphs.

[kark]

Thank you Doulgas! Looks good! Great work overall! 🚀