[KalturaAPI]: All card implementations should retrieve and display video title/duration

Description

The only component that fetches video duration information from Kaltura is C4DCardCTA. No components extend card-cta and no other components or mixins call either KalturaAPI.getMediaDuration() or KalturaAPI.getMediaDurationFormatted()

Component(s) impacted

All card & cta components other than card-cta

Browser

Firefox

Carbon for IBM.com version

v2-latest

Severity

Severity 2 = Aspects of design is broken, and impedes users in a significant way, but there is a way to complete their tasks. Affects major functionality, has a workaround.

Application/website

ibm.com

Package

@carbon/ibmdotcom-web-components

CodeSandbox example

https://iciuc--carbon-demos.netlify.app/video-cta

Steps to reproduce the issue (if applicable)

No response

Release date (if applicable)

No response

Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

The only component that fetches video duration information from Kaltura is C4DCardCTA. No components extend card-cta and no other components or mixins call either KalturaAPI.getMediaDuration() or KalturaAPI.getMediaDurationFormatted()

This isn't true. There are other ways the duration is fetched, via theCTAMixin. In the CTAMixin updated lifecycle method, an event gets dispatched called eventRequestVideoData (c4d-cta-request-video-data) anytime the ctaType changes, which when ctaType === 'video', it does. This event is handled in C4DVideoCTAComposite (<c4d-video-cta-composite> / <c4d-video-cta-container>), which triggers a request to Kaltura for the video metadata including title, description and duration. In this way, anything using the CTAMixin with a ctaType === 'video', fetches data from Kaltura. When that request comes back, two things happen. An event is fired called eventRequestAdditionalVideoData (c4d-cta-request-additional-video-data) with the videoName and videoDuration. Second, it sets the videoName, videoDescription and videoDuration properties of the component that triggered the event, eg. the card. Those properties are reactive and trigger a re-render, at which point the video metadata is incorporated into the HTML. The result depends on which card is in play:

<c4d-card> - Renders the title of the video (videoName) in the shadow root, as a <c4d-card-heading part="caption">. That component gets a slot attribute of heading assigned to it by default. It does this regardless of whether a custom heading was given in the Light DOM of the component. Within the updated lifecycle method, when videoDuration, videoName change, it will set those same properties of the <c4d-card-footer> child element, which actually doesn't do much. <c4d-card> also has an event listener for eventRequestAdditionalVideoData (c4d-cta-request-additional-video-data), which then sets the duration string in the default slot of the <c4d-card-footer> component. As such, <c4d-card> depends on <c4d-video-cta-composite> setting its reactive properties and the eventRequestAdditionalVideoData event.
<c4d-card-group-item> - This is mostly a derivative of <c4d-card>, so all of that description applies here.
<c4d-cta cta-style="card"> / <c4d-card-cta> - Renders the title of the video as a caption in the <c4d-card-cta> shadow root. Sets videoDuration, videoName, and videoDescription properties of the <c4d-card-cta-footer>, which in turn renders the default slot in addition to a caption, which is the duration if present as "mm::ss min". You end up with the video title dynamically as well as the video duration in the footer.
<c4d-cta cta-style="card-link"> / <c4d-card-link-cta> - This is the buggiest of the bunch. It mostly acts like the <c4d-card-cta>, but it has some buggy behavior in C4DCTAHead::_handleVideoTitleUpdate method that will overwrite any child elements of <c4d-card-link-cta> with the video title and duration, which do not get slotted into the shadow DOM at all, so they're not visible.

Also of note is that <c4d-cta> (and all of its sub-variants, or "CTA Styles") are deprecated in favor of c4d-card, c4d-feature-card, c4d-link-with-icon, and c4d-button-group. They should not be used.

CodeSandbox example https://iciuc--carbon-demos.netlify.app/video-cta

I also have been reviewing the demo, but wanted to suggest some changes to clean it up and put all examples on equal playing field, wrt attributes and expected child markup. See this PR: https://github.com/andy-blum/carbon-demo/pull/1

Here is a reproduction of the page where the problem was originally reported:

https://author-p131558-e1411560.adobeaemcloud.com/content/adobe-cms/language-masters/en/qa-releases-stage/mo-test-pages/block--card.html?wcmmode=disabled

The <c4d-card-group-item> component is specifically having an issue with fetching the duration from Kaltura. After extensive debugging, it appears that there is a race condition. The key event which kicks off fetching Kaltura data, eventRequestVideoData (c4d-cta-request-video-data) fires before <c4d-video-cta-container> is defined, which is the component that is listening for that event and kicks off a request to Kaltura. Without it being defined, the event falls on deaf ears, and the Kaltura API is never called. As such there is a hidden dependency between <c4d-card-group-item> and <c4d-video-cta-container>. We could either force the library clients to load them in the right order, or import <c4d-video-cta-container> from <c4d-card-group-item> to ensure that it's present and defined first. I've asked the team to pursue the first option first.

We could either force the library clients to load them in the right order, or import from to ensure that it's present and defined first. I've asked the team to pursue the first option first.

A third option could be to wrap up the offending code in a promise that runs after we're sure the container is on the page.

if (changedProperties.has('ctaType') && ctaType === CTA_TYPE.VIDEO) {
  if (typeof videoDuration === 'undefined') {

    // Wait for the container to be ready without blocking
    customElements.whenDefined(`${prefix}-video-cta-container`)
      .then(() => {
        // Now that it's ready, dispatch our event
        this.dispatchEvent(
          new CustomEvent(eventRequestVideoData, {
            bubbles: true,
            cancelable: true,
            composed: true,
            detail: {
              href,
              videoName,
              videoDescription,
            },
          })
        );
      })
  }
}

We could either force the library clients to load them in the right order, or import from to ensure that it's present and defined first. I've asked the team to pursue the first option first.

A third option could be to wrap up the offending code in a promise that runs after we're sure the container is on the page.
if (changedProperties.has('ctaType') && ctaType === CTA_TYPE.VIDEO) {
  if (typeof videoDuration === 'undefined') {

    // Wait for the container to be ready without blocking
    customElements.whenDefined(`${prefix}-video-cta-container`)
      .then(() => {
        // Now that it's ready, dispatch our event
        this.dispatchEvent(
          new CustomEvent(eventRequestVideoData, {
            bubbles: true,
            cancelable: true,
            composed: true,
            detail: {
              href,
              videoName,
              videoDescription,
            },
          })
        );
      })
  }
}

I like that. Lets just do both to be double sure, that is, see how the clientlib team does with expressing the dependency and making use of the promise.

carbon-design-system / carbon-for-ibm-dotcom