Add createDamVideoBlock factory - #6224
Draft
VPS-julia wants to merge 4 commits into
Draft
Conversation
Sites can't always support every video option the DamVideoBlock offers, for instance autoplay isn't available in the MyAudi app. Editors were still shown switches for options that had no effect on the site. The factory takes the options a site actually supports via `supports`. Options that are left out aren't rendered in the block's admin component anymore, so editors only see what the site can honour. Values that are already stored stay untouched, they just can't be changed anymore. `DamVideoBlock` is now created with the factory and is still exported next to it, so existing applications don't need to change anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122q24Ne7m2yzMvkrA8sCVu
VPS-julia
changed the title
createDamVideoBlock factory
… test The jsdom test rendered VideoOptionsFields in isolation, because the block's admin component needs a DAM config, Apollo and upload context. Storybook already provides all of that through its decorators, so a story can exercise the real block instead of a component pulled out of it. This also matches how the equivalent option on createTipTapRichTextBlock is covered, and the stories run in CI as part of the storybook test project. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0122q24Ne7m2yzMvkrA8sCVu
Shows the extreme case of the factory: with `supports: []` the editor is left with just the file to choose. Also documents that the preview image isn't a video option and stays, and that showControls keeps its default so the video is still usable without any option set.
The MyAudi Discover Tab transform forwards only the video's DAM fileUrl; the still comes from the Stage block's own backgroundImage. A preview image on the video would be filled in by editors and then never reach the app. Add "previewImage" to `supports` so it can be left out like the other options. The preview image stays part of the block's data either way, since the API's child block is non-nullable and the default empty PixelImage block fills it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
DamVideoBlockalways offers editors all three video options: autoplay, loop and show controls. Not every site can honour all of them — for instance, embedded app contexts commonly can't autoplay videos at all.Today there is no way to take an option away. Editors are shown a switch, they turn it on, and nothing happens on the site. There's also no way to configure the block at all, since it's exported as a finished object rather than built by a factory.
Solution
Add a
createDamVideoBlockfactory, analogous tocreateRichTextBlock. It takes the options a site actually supports viasupports; anything left out isn't rendered in the block's admin component, so editors only see switches that have an effect.DamVideoBlockis now created by calling the factory with defaults and is still exported next to it, so this is non-breaking — existing applications don't need to change anything.Two details worth pointing out for review:
autoplay: true. That avoids a silent data change on the next save. If clearing unsupported options is wanted, it should be a deliberate follow-up.showControlswould have silently enabled an autoplay the site can't do.Example usage
A site that can't autoplay videos:
The factory also takes
tagsand the usualoverridecallback.Example
blocks/__stories__/DamVideoBlock.stories.tsx— aDefaultstory and aWithoutAutoplaystory built withsupports: ["loop", "showControls"], following the same pattern as thesupportsstories forcreateTipTapRichTextBlock. Theirplayfunctions assert which switches are offered, that switching off show controls enables autoplay in the default block, and that it does not enable the unsupported autoplay in the restricted one.Plus
createDamVideoBlock.test.tsxfor the factory's name,tagsandoverride.Changeset
Added,
minorfor@dextinity/cms-admin.Scope
Admin only. An API-side factory can't currently satisfy the non-breaking requirement:
createBlockauto-registers by name (packages/api/cms-api/src/blocks/block.ts:326) and the nameDamVideois persisted in content, so a project calling the factory would double-registerDamVideoalongside the library's eager export. Nothing was needed on the API side anyway — the video option fields are alreadynullable/@IsOptional.🤖 Generated with Claude Code
https://claude.ai/code/session_0122q24Ne7m2yzMvkrA8sCVu