Skip to content

Conversation

@Shreyas281299
Copy link
Contributor

COMPLETES N/A - Documentation Enhancement

This pull request addresses

Adding AI-optimized documentation for the cc-widgets package to help AI assistants understand the Web Component wrappers using r2wc.

by making the following changes

  • Added packages/contact-center/cc-widgets/ai-docs/AGENTS.md - Usage documentation and custom element registration
  • Added packages/contact-center/cc-widgets/ai-docs/ARCHITECTURE.md - Technical r2wc implementation details

Change Type

  • 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)
  • Documentation update
  • Tooling change
  • Internal code refactor

The following scenarios were tested

  • The testing is done with the amplify link

The GAI Coding Policy And Copyright Annotation Best Practices

  • GAI was not used (or, no additional notation is required)
  • Code was generated entirely by GAI
  • GAI was used to create a draft that was subsequently customized or modified
  • Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
  • Tool used for AI assistance (GitHub Copilot / Other - specify)
    • Github Copilot
    • Other - Please Specify: Cursor AI
  • This PR is related to
    • Feature
    • Defect fix
    • Tech Debt
    • Automation

Checklist before merging

  • I have not skipped any automated checks
  • All existing and new tests passed
  • I have updated the testing document
  • I have tested the functionality with amplify link

Make sure to have followed the contributing guidelines before submitting.

@aws-amplify-us-east-2
Copy link

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-597.d1b38q61t1z947.amplifyapp.com

| `@webex/cc-task` → CallControlCAD | `CallControlCAD` | `widget-cc-call-control-cad` | `onHoldResume`, `onEnd`, `onWrapUp`, `onRecordingToggle` |
| `@webex/cc-task` → OutdialCall | `OutdialCall` | `widget-cc-outdial-call` | None (uses store) |

### File Structure
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File Structure should be placed before widget mapping and since we have package structure also so they should be together

### Purpose

CC Widgets serves as the main entry point and bundle for contact center widgets. It:
- **Aggregates all widgets** from individual packages into a single bundle
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expanding the statement to say all widgets to actually name them in bracket next to it. Or saying Aggregates each widget module/package(station-logn, user-state etc) from individual packages into a single bundle


### Purpose

CC Widgets serves as the main entry point and bundle for contact center widgets. It:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are already talking about how CC widgets is a combine dsingle bundle for each of the widgets so here we can just that it's the main entry point for contact center widgets


### Key Capabilities

- **Dual Export System**: Import as React components or use as Web Components
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we are mentioning the same things in purpose and key capabilities but just in different words. Purpose shuld be more on high level I guess that why was this package created and in kep capabilities we can list down more in detail on what all the package does

initCC();

// Add event listeners
const loginWidget = document.querySelector('widget-cc-station-login');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we suggesting to do this and from which perspective we have listen like this ? I cannot find any reference for this code


---

## Dependencies
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel dependencies and available widgets list should come before the usecases or examples


### 1. React Bundle (`dist/index.js`)

```typescript
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do these points have to be inside the code block and as commented lines ? Does it read better like this ? It's not an actual code line so could be just mentioned as plain bullet points

| **React Bundle** | `src/index.ts` | Re-exports React widgets | `dist/index.js` | React applications |
| **Web Components** | `src/wc.ts` | r2wc wrappers + registration | `dist/wc.js` | HTML/vanilla JS/other frameworks |

### Widget Mapping
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This information seems repetetive between Agents.md and Architecture.md file. Under available widgets we are telling the same as separate sections and here in form of table


### React Export Flow

```mermaid
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a parse error in this diagram: Parse error on line 3:
...t Packages" SL[@webex/cc-station when I try to display its rich diff to preview the page


---

## Troubleshooting Guide
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This list seem to be specific defined list for issues seen. But would there be a general troubleshooting guidelines, then only we should have this heading and we should those general rules under that. Else Just saying Common Issue and their Solution as heading then listing those down is enough

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants