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]

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

[namArora3112]

Mutating props directly is generally an anti-pattern. Instead of changing the prop object, can we handle this using internal useState or by emitting an event so the parent updates the list data?

[jkartoshka]

moved to the usage of an internal useState

[namArora3112]

Use Linking.canOpenURL() and await Linking.openURL() with try/catch to avoid silent failures.

[jkartoshka]

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

[namArora3112]

I noticed that each <Button> receives the same onPress={onPress} handler, but onPress opens template.data.content.actionUrl.
Since each button has its own button.actionUrl, shouldn’t the tap action open the specific button’s URL instead of the card-level URL?
<Button key={button.id} title={button.text.content} onPress={onPress} // opens template.data.content.actionUrl ... />
Should this instead call a handler like handleButtonPress(button) so we correctly open button.actionUrl and track the right interaction?

Just checking the intended behaviour here — is it expected that all buttons open the same action URL, or should each button trigger its own?

[jkartoshka]

added onButtonPress for button specific behavior

[namArora3112]

Can we define the types if possible?

[jkartoshka]

changed to const content = template?.data?.content as ContentCardContent;

[namArora3112]

Noticed that all buttons are using the same onPress callback, so it’s unclear how we distinguish which button was clicked. Should we pass a button ID or some identifier to the handler, or is the current approach intentional?

[jkartoshka]

added logic for the interact id interactId={button.id}

[namArora3112]

From a UI perspective, should we consider adding an image-loading indicator? This would give users feedback while the image is being fetched.
Something like the snippet below could help manage loading and error states:

const [imageError, setImageError] = useState(false);
const [imageLoading, setImageLoading] = useState(true);

<Image
  source={{ uri: imageUri }}
  onLoadStart={() => setImageLoading(true)}
  onLoadEnd={() => setImageLoading(false)}
  onError={() => {
    setImageError(true);
    setImageLoading(false);
  }}
  style={[
    // ...styles
    imageLoading && { opacity: 0.5 },
  ]}
  {...ImageProps}
/>

{imageLoading && <ActivityIndicator />}

[namArora3112]

Add it to color constant

[jkartoshka]

added imageContainerColor to theme colors interface

[namArora3112]

In few places we are using useTheme hooks but here we are using useColorScheme . Is it intentional?

[jkartoshka]

moved to usage of useTheme everywhere & removed useColorScheme

[namArora3112]

Using lowercase "x" is not standard. Should use "×" (multiplication sign) or an icon.

[namArora3112]

It might be better to use a cross icon instead of text here. Using text can shift or distort the button layout when system font settings change.

[jkartoshka]

Moved to usage of multiplication sign unicode

[namArora3112]

I don’t see any recent (RN 0.70+) documentation or benchmarks that explicitly call out extremely high zIndex values (like 1000) as a performance bottleneck — but there are several past and known issues in React Native that make me cautious about using such high values:

• On Android, very large or dynamically changing zIndex in a FlatList header has been reported to cause hard crashes. ([Stack Overflow]1)
• zIndex + position: 'absolute' can behave inconsistently on Android unless component order and elevation are handled properly. ([Stack Overflow]2)
• There was a long‑standing bug in older RN versions (v0.45–0.48) where Android would not re-render views correctly when zIndex changed dynamically. ([reubenab.github.io]3)
• Multiple developers have reported unstable rendering (e.g. flickering or disappearing components) when relying heavily on zIndex, advising use of elevation on Android instead. ([Stack Overflow]4)
• There are cases where zIndex is “not taken seriously” on Android or gets overridden by elevation. ([Stack Overflow]5)

Recommendation:
Let’s reduce the zIndex to the minimum needed to achieve the stacking effect, instead of using a very large arbitrary number. On Android, we should prefer using elevation (or a combination of moderate zIndex + elevation) for more predictable behavior.

---

[jkartoshka]

removed zIndex: 1000 on DismissButton as stacking is handled by render order + absolute positioning

[namArora3112]

Please add this to color constant

[jkartoshka]

moved to the usage of useTheme colors

[namArora3112]

try to add color constants

[jkartoshka]

moved to the usage of useTheme colors

[namArora3112]

We already have a useTheme hook implemented. To maintain consistency across the codebase, it would be better to use useTheme (or similar theme/color hooks) or useColorScheme. Whatever you feel fine..

[jkartoshka]

came to a decision to use useTheme to maintain consistency through the codebase

[namArora3112]

add color constants

[jkartoshka]

added activeColor to colors interface

[namArora3112]

add color constants

[jkartoshka]

added inactiveColor to colors interface

[namArora3112]

Need to stop animations at the time of clean up

 return () => {
     // stop both if unmounted
     scaleAnim.stopAnimation();
     opacityAnim.stopAnimation();
   };
   ```

[jkartoshka]

added stopAnimation at time of clean up to Pagination

[namArora3112]

Add color constants

[jkartoshka]

added dotColor to colors interface

[namArora3112]

Please dont use such high value for zIndex

[jkartoshka]

removed zIndex: 1000 on UnreadIcon as stacking is handled by render order + absolute positioning

[namArora3112]

Can we use useTheme hook or not?

[jkartoshka]

changed to usage of useTheme

[namArora3112]

remove this state as we are already setting it to false in finally black

[jkartoshka]

removed setIsLoading(false);

[namArora3112]

remove this as we are already doing in finally block

[jkartoshka]

removed setIsLoading(false);

[namArora3112]

just thinking the use case if someone want to toggle the themes in the content card itself. if so then we have to expose the setTheme function too

[namArora3112]

A couple of things appear to be missing from this PR:

Accessibility support for the UI elements – we should ensure proper accessibility labels, roles, and hints are included.

data-test-id attributes – are we planning to add UI test cases? If so, these identifiers will be needed to reliably target elements in tests.

Adding these will help improve both accessibility and testability of the components.