LPD-24670 WIP.

[dsanz]

Context: https://liferay.atlassian.net/browse/LPD-24670

Goal is to check selected item has no visualization modes, to render it differently

How it looks like
With this commit, a Data Set with no visualization mode appears with a warning icon:

Problem: in the case of list visualization, we need to mutate item as ClayList.Item does not take any prop we can remap.

Proposal to handle this case for list views, which we can use in all views:

• Extend api to allow a setItemProps function that returns a modified item to be consumed by views.
• Use it from views as follows (example with List):

const ListItem = forwardRef<HTMLLIElement, any>(
	(
		{
			className,
			item: originalItem,
			...
		}: {
			...
		},
		ref
	) => {
...

		const item = {...originalItem, activeView.setItemProps?.({originalItem})}		

		// use item normally
		const itemId = getObjectValueFromPath({
			object: item,
			path: selectedItemsKey,
		});

...

		return (
			<ClayList.Item
				{...props}
				{...(activeView.setItemComponentProps?.({item, props}) ?? {})}
				ref={ref}
			>

This came from a quick peer session with @chestofwonders

cc @markocikos as you designed this solution, pls chime in and share yout thougths

[liferay-continuous-integration]

CI is automatically triggering the following test suites:

•     ci:test:sf

[liferay-continuous-integration]

Test suite sf has been triggered on http://test-1-32

[liferay-continuous-integration]

✔️ ci:test:sf - 1 out of 1 jobs passed in 3 minutes

Ran com.liferay.source.formatter at released version 1.0.1543.
*The latest version has not been released.

Click here for more details.

Base Branch:

Branch Name: master
Branch GIT ID: ba9d2ba803a68c8d511640bc697f5266cada47d8

Sender Branch:

Branch Name: LPD-24670
Branch GIT ID: 9b587ce85528b7eb6969c2f9f9d18525b86975ef

1 out of 1 jobs PASSED

1 Successful Jobs:

• test-portal-source-format

For more details click here.

[liferay-continuous-integration]

Jenkins Build:test-portal-source-format#10886

Jenkins Report:jenkins-report.html

Jenkins Suite:sf

Pull Request:liferay-frontend#5110

Testray Routine:EE Pull Request

Testray Build:[master] ci:test:sf - dsanz > liferay-frontend - PR#5110 - 2025-10-07[04:29:07]

Testray Build ID:334418936

Testray Importer:test-portal-source-format#10886

[dsanz]

@markocikos I've added an extra commit that solves the item mutation issue, but changes a bit the application of setItemComponentProps in List.

[markocikos]

@dsanz @chestofwonders please see comment inline

[markocikos]

My first feeling about this was that it wasn't right, because API was intended to modify props of component implementing the item, <ClayList.Item>. It does make sense to shift target of customization to <ListItem>, our own wrapper of the component. It makes customization of our implementation more flexible. But. it's a tradeoff. We lose future-proof aspect of the solution, where devs would automatically be able to modify future props of <ClayList.Item>. It might make sense to add a prop specifically for that purpose. Something like

const props = {
		className,
		clayListItemProps, // new prop
		item,
		items,
		onItemSelectionChange,
		ref:dropRef,
		schema,
	};

<ListItem
		{...props}
		{...(activeView.setItemComponentProps?.({item, props}) ?? {})}

that ends up in

<ClayList.Item
	className={classNames(className, {
		active: selectedItemsValue?.includes(itemId),
	})}
	flex
	{...clayListItemProps}
>

In general, mutating item is not good practice, but I think it's acceptable this close to leaf usage.

What do you think?

[dsanz]

Doing this shift makes item not mutated indeed.

Note how first commit does item.foo = bar whereas second one just provides a different item. So no internal FDS state is mutated.

It's true that we are changing the item we pass to the child component. I believe there's a slight difference between this and mutating the item.

And yes, what you say makes sense to me, we need to open the possibility to drill down props in the "real" target component here. @chestofwonders pls add this to #5122 so that devs have access to the underlying <ClayList.Item> so that we get the best of both worlds

Thank you @markocikos !

[dsanz]

Pls see #5122