Content card containers

[dsoffiantini]

Background -
We're implementing the Messaging Inbox feature with support for:
1. Container Settings - The SDK reads container payload and displays content according to supported settings configured via AJO Authoring UI (experience.adobe.com).
2. Content Card Templates - Support for displaying content cards with various templates (SmallImage, LargeImage, ImageOnly). See our usage documentation for implementation details.

Key Changes -
Most of the additions are located in the packages/messaging/src/ui/ folder, which contains:
• React components for Content Card rendering (ContentCardContainer, ContentCardView…)
• Supporting UI components (Button, DismissButton, UnreadIcon, EmptyState)
• Hooks for data fetching (useContentCardUI, useContentContainer…)
• Theme system and styling

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[namArora3112]

Is this accidentally committed ?

[jkartoshka]

removed .cursorignore file

[namArora3112]

this change should be reverted before merging

[jkartoshka]

reverted back to com.AEPSampleAppNewArchEnabled

[namArora3112]

i think we dont need this ..

[namArora3112]

earlier we were not adding dist folder to commit. any reason that why have added it to our version control now

[jkartoshka]

We use this to distribute the binaries to the beta testing team while we’re unable to publish to npm.

[namArora3112]

We should use Linking.canOpenURL() in order t o validate the links .

const supported = await Linking.canOpenURL(actionUrl);

if (supported) {
  Linking.openURL(actionUrl);
} else {
  console.warn(...)
}

https://reactnative.dev/docs/linking#openurl:~:text=This%20method%20will%20fail%20if%20the%20system%20doesn%27t%20know%20how%20to%20open%20the%20specified%20URL.%20If%20you%27re%20passing%20in%20a%20non%2Dhttp(s)%20URL%2C%20it%27s%20best%20to%20check%20canOpenURL()%20first.%20For%20web%20URLs%2C%20the%20protocol%20(%22http%3A//%22%2C%20%22https%3A//%22)%20must%20be%20set%20accordingly!

[jkartoshka]

Added Linking.canOpenURL() logic to Button.tsx for link validation

[namArora3112]

The id prop is declared but not utilized anywhere in the component.

[jkartoshka]

removed unnecessary id prop from Button.tsx

[namArora3112]

The handlePress callback currently does not accept the GestureResponderEvent emitted by Pressable. As a result, onPress consumers never receive the event, even though the component’s type signature indicates that the event should be forwarded.

This creates an inconsistency between the API contract and the implementation.

Proposed fix:

const handlePress = (event: GestureResponderEvent) => {
  onPress?.(interactId, event);
  if (actionUrl) {
    Linking.openURL(actionUrl).catch(...);
  }
};

This keeps the API consistent and prevents unexpected undefined events in parent components.

[jkartoshka]

Added GestureResponderEvent to handlePress callback in Button.tsx

[namArora3112]

textStyle?: TextStyle | TextStyle[];
It can be simplified to this

[jkartoshka]

changed to textStyle?: StyleProp<TextStyle>; to match Reacy Native’s style prop and allow arrays, null/undefined/false, and registered/animated styles without type errors.

[namArora3112]

PropsWithChildren needs a generic type (e.g. {}) — otherwise it becomes any.
So it can be written like this
PropsWithChildren<{}>;

[jkartoshka]

changed to PropsWithChildren<ViewProps>

[namArora3112]

Just to clarify: this will occupy the entire screen — is that the intent? If so, it seems we should be using or creating a FullScreenCenterView, since the current name is a bit confusing.

[jkartoshka]

changed CenteredView to be called FullScreenCenterView

[namArora3112]

An appropriate accessibilityRole should also be defined for this component.

[jkartoshka]

Added accessibilityRole = 'button', but also added it as an optional prop if user wants to change it to something else: accessibilityRole?: AccessibilityRole; in Button.tsx

[namArora3112]

If heading is undefined, the component will throw when attempting to access heading.content.
Even though heading is marked as a required prop in contentSettings, it may still be missing at runtime.

If you want to add guard rails, you can safely render the heading using the following pattern:

{heading?.content ? (
  <Text
    accessibilityRole="header"
    style={[styles.heading, { color: headingColor }]}
  >
    {heading.content}
  </Text>
) : null}

[jkartoshka]

Applied the above pattern to heading in ContentCardContainer.tsx as a guard rail

[namArora3112]

Quick question — why are we passing refetch to extraData?
My understanding is that extraData should be used for UI state that affects item rendering, but refetch is just a function and won’t trigger meaningful re-renders.

[jkartoshka]

removed extraData={refetch} from the ContentCardContainer, it was being used as a workaround, but not needed anymore

[namArora3112]

It can also be written like this
style={isHorizontal ? [styles.horizontalCardStyles, { width: Math.floor(windowWidth * 0.75) }] : undefined}

[jkartoshka]

rewritten to

style={
   isHorizontal 
      ? [styles.horizontalCardStyles, { width: Math.floor(windowWidth * 0.75) }]
      : undefined
}

[namArora3112]

We should implement a keyExtractor for this FlatList so it can render more efficiently and avoid unnecessary re-renders.

[jkartoshka]

Added keyExtractor={(item: { id: string }) => item.id} to this FlatList

[namArora3112]

can we move the color string to constants

[jkartoshka]

moved to usage of useTheme colors constant

[namArora3112]

As it is a typescript file we should add proper types for state
For ex:
useState<Set<string | number>>(new Set())

[jkartoshka]

changed to const [dismissedIds, setDismissedIds] = useState<Set<string>>(new Set());

[namArora3112]

Can you confirm if this has been manually tested by rotating the device from portrait to landscape, especially for the horizontal FlatList case?
useWindowDimensions should recalculate the width automatically, but I just want to make sure none of the styles break when the orientation changes.

[namArora3112]

Quick question: why didn’t we wire refetch to the FlatList onRefresh prop? Is there a reason we handled refresh differently?

[jkartoshka]

removed refetch logic from ContentCardContainer as it is not needed anymore

[namArora3112]

We should avoid creating a new inline listener inside renderItem for every item. This causes unnecessary re-renders and prevents ContentCardView from taking advantage of memoization.

If ContentCardView passes the card's id when firing the event (e.g., listener(event, item.id)), we can use a single shared callback:

const handleCardEvent = useCallback((event, itemId, ...rest) => {
  if (event === "onDismiss") onDismiss(itemId);
  CardProps?.listener?.(event, itemId, ...rest);
}, [onDismiss, CardProps]);

<ContentCardView
  template={item}
  {...CardProps}
  listener={handleCardEvent} // shared, stable listener
/>

This avoids per-item function creation and improves FlatList performance.

[jkartoshka]

added the usage of a new single shared callback:

const handleCardEvent = useCallback(
    (event?: ContentViewEvent, data?: ContentTemplate, nativeEvent?: any) => {
      if (event === 'onDismiss' && data?.id) {
        setDismissedIds((prev) => {
          const next = new Set(prev);
          next.add(data.id as any);
          return next;
        });
      }
      CardProps?.listener?.(event, data, nativeEvent);
    },
    [CardProps]
  );

[namArora3112]

Should localise it or use constants for rendering text

[jkartoshka]

added a constant for "No Content Available"

[namArora3112]

Just a quick question: Should we add fallback image or not for network failure cases