feat: Feature notifications by georgylobko · Pull Request #4186 · cloudscape-design/components

georgylobko · 2026-01-14T10:16:44Z

Description

Introduced a feature notifications API that allows dynamically injecting a feature notifications drawer on pages using the AppLayout component.

The new API includes 3 methods:

registerFeatureNotifications - registers a new drawer
showFeaturePromptIfPossible - manually shows a feature prompt next to the drawer's trigger button
clearFeatureNotifications - clears the feature notifications drawer

Also enhanced the existing feature prompt internal component by adding dismissal context to the onDismiss method (blur, close-button, outside-click, etc.).

Related links, issue #, if available: n/a

How has this been tested?

U tests / manually

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

Changes include appropriate documentation updates.
Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
Changes do not include unsupported browser features, see CONTRIBUTING.md.
Changes were manually tested for accessibility, see accessibility guidelines.

Security

If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

Changes are covered with new/existing unit tests?
Changes are covered with new/existing integration tests?

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

codecov · 2026-01-14T11:33:15Z

Codecov Report

❌ Patch coverage is 99.48454% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 97.37%. Comparing base (e135e95) to head (1618aa1).

Files with missing lines	Patch %	Lines
...efresh-toolbar/state/use-feature-notifications.tsx	99.09%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4186      +/-   ##
==========================================
+ Coverage   97.35%   97.37%   +0.01%     
==========================================
  Files         889      891       +2     
  Lines       26040    26210     +170     
  Branches     9417     9485      +68     
==========================================
+ Hits        25352    25521     +169     
- Misses        641      642       +1     
  Partials       47       47

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

georgylobko · 2026-02-17T16:15:39Z

src/internal/do-not-use/feature-prompt/interfaces.ts

   * clicking outside the prompt, shifting focus out of the prompt or pressing ESC.
   */
-  onDismiss?: NonCancelableEventHandler<null>;
+  onDismiss?: NonCancelableEventHandler<{ method?: string }>;


The method is a way the feature prompt was closed - blur, escape, close-button, click-outside.

…re prompt

pan-kot · 2026-02-18T12:48:48Z

src/plugins/index.ts

+'use client';
+export * from '../internal/plugins/widget/interfaces';
+export {
+  registerFeatureNotifications,


Should we group the APIs, same as we do for internal ones?

Like:

const api = { featureNotifications: { registerFeatureNotifications, showFeaturePromptIfPossible, clearFeatureNotifications, } } export default api;

pan-kot · 2026-02-18T13:49:21Z

pages/feature-notifications/feature-prompt.page.tsx

+  id: 'local-feature-notifications',
+  suppressFeaturePrompt: false,
+  featuresPageLink: '/#/feature-notifications/feature-prompt?appLayoutToolbar=true',
+  filterFeatures: () => true,


nit: The filterFeatures is unnecessary here

pan-kot · 2026-02-18T13:50:43Z

pages/feature-notifications/feature-prompt.page.tsx

+  persistenceConfig: {
+    uniqueKey: 'feature-notifications',
+  },
+  // DON'T USE


What is this comment about?

pan-kot · 2026-02-18T13:57:18Z

src/app-layout/__tests__/runtime-feature-notifications.test.tsx

+});
+
+function delay() {
+  return act(() => {


Is act() really needed? I think the delay() function can potentially be replaced with jest.runAllTimersAsync() or, better, jest.advanceTimersByTimeAsync(time).

Also, the name "delay()" it not semantically sound as we do not use it to delay anything - we use it to wait for the component delays.

pan-kot · 2026-02-18T13:57:46Z

src/app-layout/__tests__/runtime-feature-notifications.test.tsx

+async function renderComponent(jsx: React.ReactElement) {
+  const { container, rerender, ...rest } = render(jsx);
+  const wrapper = createWrapper(container).findAppLayout()!;
+  await delay();


why do we call delay() here?

Even if that is needed for all tests to wait until the initial appearance of feature notifications - I would call it explicitly in each test suite to represent the intent better.

pan-kot · 2026-02-18T14:06:03Z

src/app-layout/__tests__/runtime-feature-notifications.test.tsx

+  test('shows feature prompt for a latest features', async () => {
+    awsuiWidgetPlugins.registerFeatureNotifications(featureNotificationsDefaults);
+    const { container } = await renderComponent(<AppLayout />);
+    await delay();


We call delay() inside renderComponent, so this call should not be necessary - there are tests where it is called and some where it is not called immediately after render. I recommend to remove it from the render helper and always call it explicitly.

pan-kot · 2026-02-18T14:07:37Z

src/app-layout/__tests__/runtime-feature-notifications.test.tsx

+    expect(persistedFeaturesMap).toHaveProperty('feature-1');
+    expect(persistedFeaturesMap).toHaveProperty('feature-2');
+    expect(persistedFeaturesMap).toHaveProperty('recent-seen-feature');
+    expect(persistedFeaturesMap).not.toHaveProperty('old-seen-feature');


nit: would it makes sense to move persistence-related tests to a separate file?

pan-kot · 2026-02-18T14:09:54Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+    if (!mountContent) {
+      return;
+    }
+    const container = ref.current!;


instead of expecting the content to be there to satisfy TS - should we include it to the if check above?

if (!mountContent || !ref.content) { return; }

pan-kot · 2026-02-18T14:15:30Z

pages/feature-notifications/feature-prompt.page.tsx

+                  Demo page
+                </Header>
+              </div>
+              <Button


nit: these buttons do not have margins between them

pan-kot · 2026-02-18T14:17:26Z

pages/feature-notifications/feature-prompt.page.tsx

 import * as toolsContent from '../app-layout/utils/tools-content';
 import ScreenshotArea from '../utils/screenshot-area';

+registerFeatureNotifications({


These only work when using appLayoutToolbar=true. I suggest to test if the non-toolbar layout does not crash when using this feature in unit tests, and always render the toolbar variant on this test page - it is confusing otherwise.

The feature does not seem to be working correctly. The prompt shows when I open dev tools, but not upon page reload. I am testing it in Chrome.

Screen.Recording.2026-02-18.at.15.18.31.mov

When feature notifications are registered (I added a delay for this to be better noticeable) - the tools disappear.

Screen.Recording.2026-02-18.at.15.24.57.mov

pan-kot · 2026-02-18T14:30:33Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+  const i18n = useInternalI18n('features-notification-drawer');
+
+  return (
+    <InternalDrawer header={i18n('i18nStrings.title', undefined)} disableContentPaddings={true}>


This means that the feature cannot be used w/o built-in i18n, and that changing the default messages is only possible with a workaround (by overriding our messages objects).

Should we include (optional) i18nStrings to the runtime API instead?

pan-kot · 2026-02-18T14:33:42Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+            ),
+            secondaryContent: (
+              <>
+                {!!item.releaseDate && (


The releaseDate is required as per our types.

pan-kot · 2026-02-18T14:36:13Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+            secondaryContent: (
+              <>
+                {!!item.releaseDate && (
+                  <Box margin={{ top: 'xs' }} fontSize="body-s" color="text-body-secondary">


There is already a default padding between content and secondary content - why do we add some more?

Can we use space-between instead of boxes with margins?

pan-kot · 2026-02-18T14:42:57Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+      destructor?.();
+    };
+    // eslint-disable-next-line react-hooks/exhaustive-deps
+  }, []);


I would add a unit tests where registerFeatureNotifications is called multiple times - sync or async, to assert that the latest content and the latest mountItem are used.

pan-kot · 2026-02-18T14:44:52Z

src/app-layout/visual-refresh-toolbar/drawer/feature-notifications-drawer-content.tsx

+    <InternalDrawer header={i18n('i18nStrings.title', undefined)} disableContentPaddings={true}>
+      <Box
+        padding={{ top: 'm', left: 'xl', right: 'xl', bottom: 'm' }}
+        className={styles['runtime-feature-notifications-drawer-content']}


Overriding styles on our components is not recommended. Can we use a custom div here instead?

The same applies to the .runtime-feature-notifications-footer

pan-kot · 2026-02-18T14:48:39Z

src/app-layout/visual-refresh-toolbar/drawer/styles.scss

  }
 }
+
+.runtime-feature-notifications-drawer-content {


Do we have plans to support test-utils for this feature? I believe we should, as the consumers should have a reliable way to assert the feature prompt and drawer content.

pan-kot · 2026-02-18T14:54:55Z

src/app-layout/visual-refresh-toolbar/state/use-app-layout.tsx

  };

+  const { featureNotificationsProps, onOpenFeatureNotificationsDrawer, featureNotificationsMessageHandler } =
+    useFeatureNotifications({ getDrawersIds: () => drawers?.map(drawer => drawer.id) ?? [] });


Why is it necessary to pass the getDrawersIds to the hook? The feature notifications should not care about other drawers.

If I understand it correctly, the registerFeatureNotifications API is responsible for rendering the drawer and also the feature prompt. Can this two actions be joined? For instance, the featureNotificationsProps.drawer can include an optional featurePrompt object - describing the prompt. When it is present - the prompt is shown, but only during the initial render (app layout would handle that).

Otherwise, there is a bi-directional connection between the app layout state and feature notifications state, which can cause race conditions and is overall difficult to understand.

pan-kot · 2026-02-18T15:09:11Z

src/app-layout/visual-refresh-toolbar/state/use-feature-notifications.tsx

+
+      setFeatureNotificationsData({ ...payload, features });
+
+      const persistenceConfig = payload.persistenceConfig ?? DEFAULT_PERSISTENCE_CONFIG;


nit: I would add some code comments here explaining the relation between the event payload and the data we extract from the persistence mechanism.

pan-kot · 2026-02-18T15:12:43Z

src/app-layout/visual-refresh-toolbar/state/use-feature-notifications.tsx

+      const persistenceConfig = payload.persistenceConfig ?? DEFAULT_PERSISTENCE_CONFIG;
+      const __retrieveFeatureNotifications:
+        | ((persistenceConfig: FeatureNotificationsPersistenceConfig) => Promise<Record<string, string>>)
+        | undefined = (payload as any)?.__retrieveFeatureNotifications;


Can this __retrieveFeatureNotifications be used from the public API? If so - do we have use cases besides testing? If no - I recommend doing some internal version of the API that allows it and make sure that everything starting from __ is omitted from the public plugin (using getExternalProps util).

pan-kot · 2026-02-18T15:14:08Z

src/app-layout/visual-refresh-toolbar/state/use-feature-notifications.tsx

+    }
+
+    if (event.type === 'showFeaturePromptIfPossible') {
+      if (markAllAsRead) {


Why do we need this extra state? Can we check the featureNotificationsData instead?

pan-kot · 2026-02-18T15:20:59Z

src/app-layout/visual-refresh-toolbar/state/use-feature-notifications.tsx

+            triggerRef?.current!.focus();
+          }
+          setFeaturePromptDismissed(true);
+          Promise.resolve().then(() => {


If the feature prompt was rendered by the app layout (with an extra internal prop on the drawer) - then we could suppress the tooltip whenever the feature prompt is present, w/o introducing the data-attributes.

Is there a reason why the feature cannot be fully controlled with the React state alone?

pan-kot · 2026-02-18T15:25:16Z

src/app-layout/visual-refresh-toolbar/state/use-feature-notifications.tsx

+    const featuresMap = featureNotificationsData.features.reduce((acc, feature) => {
+      return {
+        ...acc,
+        [feature.id]: feature.releaseDate.toString(),


the Date.toString() is browser and locale dependent. If the persistence is cross-browser - the keys won't match. If the user would change their locale - the keys won't match.

georgylobko changed the title ~~feat: Seature notifications~~ feat: Feature notifications Jan 14, 2026

georgylobko deployed to dev-pages-react16 January 14, 2026 11:32 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 14, 2026 11:32 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 14, 2026 12:08 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 14, 2026 12:08 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch from 4fa101b to efb51d9 Compare January 14, 2026 12:20

georgylobko deployed to dev-pages-react18 January 14, 2026 12:29 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 14, 2026 12:29 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 15, 2026 15:45 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 15, 2026 15:45 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch 2 times, most recently from 8343dd7 to aea04d1 Compare January 19, 2026 10:37

georgylobko deployed to dev-pages-react18 January 19, 2026 10:46 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 19, 2026 10:46 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 19, 2026 11:07 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 19, 2026 11:07 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch from 2e7cb8e to 1f4c85f Compare January 20, 2026 12:51

georgylobko deployed to dev-pages-react18 January 20, 2026 13:09 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 20, 2026 13:09 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch from 221927b to 4379ee3 Compare January 20, 2026 15:23

georgylobko deployed to dev-pages-react18 January 20, 2026 15:32 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 20, 2026 15:32 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 January 26, 2026 15:40 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 26, 2026 15:40 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch 2 times, most recently from 493d050 to fbd48d1 Compare January 27, 2026 09:31

georgylobko deployed to dev-pages-react16 January 27, 2026 09:41 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 January 27, 2026 09:41 — with GitHub Actions View deployment

georgylobko force-pushed the feat/feature-notitications branch from 9dc81fc to 6c9b625 Compare January 28, 2026 14:53

georgylobko deployed to dev-pages-react16 February 17, 2026 15:40 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 February 17, 2026 15:54 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 February 17, 2026 15:54 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react18 February 17, 2026 16:11 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 February 17, 2026 16:11 — with GitHub Actions View deployment

georgylobko commented Feb 17, 2026

View reviewed changes

georgylobko marked this pull request as ready for review February 17, 2026 16:23

georgylobko requested a review from a team as a code owner February 17, 2026 16:23

georgylobko requested review from SpyZzey, gethinwebster and pan-kot and removed request for a team February 17, 2026 16:23

georgylobko added 11 commits February 18, 2026 11:27

feat: Feature notifications plugin API

cb7d297

fix: message types format

be5b761

fix: Suppress drawer trigger tooltip after switching its from a featu…

b1be813

…re prompt

fix: Focus trap issue

ecd59d3

fix: Demo link

4c66bfb

chore: Url based persistence

012ed90

chore: Refactoring

2afe01d

chore: Bring back u tests for feature-prompt

a556936

feat: Clear feature notifications

6ce72a6

chore: Remove unnecessary code changes

57a4205

chore: Additional test coverage

1618aa1

georgylobko force-pushed the feat/feature-notitications branch from 6286dcf to 1618aa1 Compare February 18, 2026 10:27

georgylobko deployed to dev-pages-react18 February 18, 2026 10:37 — with GitHub Actions View deployment

georgylobko deployed to dev-pages-react16 February 18, 2026 10:37 — with GitHub Actions View deployment

pan-kot reviewed Feb 18, 2026

View reviewed changes


		setFeatureNotificationsData({ ...payload, features });

		const persistenceConfig = payload.persistenceConfig ?? DEFAULT_PERSISTENCE_CONFIG;

Conversation

georgylobko commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How has this been tested?

Correctness

Security

Testing

Uh oh!

codecov bot commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

georgylobko Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

georgylobko commented Jan 14, 2026 •

edited

Loading

codecov bot commented Jan 14, 2026 •

edited

Loading

georgylobko Feb 17, 2026 •

edited

Loading