AWS Integration skeleton UI

[ahmadshaheer]

Summary

Skeleton UI for AWS Integration page

• Add an entry for AWS and redirect to the cloud integration details page on clicking Configure
• Skeleton UI
  • Header
  • Hero Section
  • Services
    • services tab bar
    • Sidebar
    • Content
    • Tabs
      • Dashboard
      • Data collected

Related Issues / PR's

close https://github.com/SigNoz/engineering-pod/issues/2113
close https://github.com/SigNoz/engineering-pod/issues/2116
close https://github.com/SigNoz/engineering-pod/issues/2121
part of https://github.com/SigNoz/engineering-pod/issues/2115
part of https://github.com/SigNoz/engineering-pod/issues/2115
part of https://github.com/SigNoz/engineering-pod/issues/2122

Screenshots

2025-01-07.08-56-31.mov

Affected Areas and Manually Tested Areas

---

Important

Add AWS Integration UI skeleton with header, hero section, and services tabs.

• UI Components:
  • Add CloudIntegrationPage with Header, HeroSection, and ServicesTabs components.
  • ServicesTabs includes ServicesList, ServiceDetails, CloudServiceDashboards, and CloudServiceDataCollected.
• Routing:
  • Update IntegrationsModulePage.tsx to render CloudIntegrationPage for AWS integration.
• Utilities:
  • Add INTEGRATION_TYPES.AWS_INTEGRATION to utils.ts.
• Styles:
  • Add styles for new components in CloudIntegrationPage.style.scss and ServicesTabs.style.scss.
• Misc:
  • Add AWS integration entry in IntegrationsList.tsx with a "NEW" tag.

^{This description was created by for 0d5f982. It will automatically update as commits are pushed.}

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 35247c9 in 1 minute and 38 seconds

More details

• Looked at 1247 lines of code in 19 files
• Skipped 2 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. frontend/src/pages/Integrations/CloudIntegrationPage/ServicesSection/CloudServiceDataCollected.tsx:9

• Draft comment:
  Consider providing default values for logsData and metricsData to prevent potential runtime errors when these props are undefined.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:

1. The props are properly typed, which means TypeScript will enforce their presence at compile time. 2. This is a new component, and the types indicate these are required props, not optional. 3. If the parent component needs to handle empty states, it should do so before rendering this component. 4. Adding default values would mask potential issues in the parent component.
   The comment might have a point about runtime safety, especially if the data is loaded asynchronously. The component could be more defensive.
   However, the TypeScript types already enforce these props as required, and handling empty states should be the responsibility of the parent component that manages the data fetching.
   The comment should be deleted as it suggests a change that goes against the component's design where these props are intentionally required.

2. frontend/src/pages/Integrations/CloudIntegrationPage/ServicesSection/CloudServiceDashboards.tsx:29

• Draft comment:
  Consider providing a default value or a check for service.assets.dashboards to prevent potential runtime errors when this property is undefined.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  Since ServiceData is a TypeScript type, if dashboards was optional it would be marked with '?' in the type definition. The fact that it's used directly in the type annotation suggests it's required. TypeScript would enforce this at compile time. Adding runtime checks for required properties is generally unnecessary and adds noise to the code.
  I can't see the actual ServiceData type definition, so I'm making assumptions about its structure. The property could potentially be optional in the type definition.
  Even if the property were optional, TypeScript would force us to handle that case at compile time. Adding runtime checks for type-enforced properties goes against TypeScript best practices.
  Delete the comment. TypeScript's type system will handle this case, and adding runtime checks for type-enforced properties is redundant.

3. frontend/src/pages/Integrations/CloudIntegrationPage/CloudIntegrationPage.tsx:7

• Draft comment:
  Ensure that the components Header, HeroSection, and ServicesTabs are correctly implemented and handle their props appropriately.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The CloudIntegrationPage component in frontend/src/pages/Integrations/CloudIntegrationPage/CloudIntegrationPage.tsx is a simple component that renders other components. It doesn't have any issues, but it's important to ensure that the components it renders are correctly implemented.

4. frontend/src/pages/Integrations/CloudIntegrationPage/ServicesSection/ServicesTabs.tsx:11

• Draft comment:
  Consider fetching the list of services and service details from an API or a centralized data source to make the component more scalable and maintainable.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  While the suggestion might be valid from an architectural perspective, it's not clear if this is a temporary solution or if there's a specific reason for using static data. The comment is somewhat speculative and doesn't point to a clear, immediate issue. It's more of a future improvement suggestion without context about the current requirements or constraints.
  The suggestion could be valid if this is production code, as hardcoded data isn't scalable. However, this might be intentionally using static data for a prototype or initial implementation.
  Without more context about the project's requirements and future plans, this comment might be premature optimization or might conflict with current architectural decisions.
  Delete the comment as it's speculative and doesn't point to a clear, immediate issue that needs to be fixed. It's more of a future consideration that should be part of broader architectural discussions.

5. frontend/src/pages/Integrations/CloudIntegrationPage/ServicesSection/ServicesTabs.tsx:25

• Draft comment:
  Avoid using inline styles. Consider using external stylesheets or styled components instead.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_0jzjSlpKGYq24epy

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

❌ Changes requested. Incremental review on 99fe4b6 in 58 seconds

More details

• Looked at 75 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/types/api/integrations/types.ts:11

• Draft comment:
  The is_new property is correctly added to the IntegrationsProps interface to support the new feature of displaying a 'NEW' tag for integrations.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The is_new property is added to the IntegrationsProps interface, which is used in the IntegrationsList.tsx file to display a 'NEW' tag for new integrations. This change aligns with the PR's intent to highlight new integrations.

2. frontend/src/pages/Integrations/IntegrationsList.tsx:119

• Draft comment:
  The is_new property is used correctly to conditionally render a 'NEW' tag for integrations.
• Reason this comment was not posted:
  Confidence changes required: 0%
  The is_new property is used to conditionally render a 'NEW' tag for integrations, which is a correct implementation based on the new feature requirements.

Workflow ID: wflow_zSPrnJrkbXKfznYx

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

❌ Changes requested. Incremental review on cab2aca in 38 seconds

More details

• Looked at 188 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. frontend/src/pages/Integrations/CloudIntegrationPage/HeroSection/HeroSection.tsx:1

• Draft comment:
  React import is missing. Add import React from 'react'; at the top for JSX to work properly.

import React from 'react';

• Reason this comment was not posted:
  Comment was on unchanged code.

2. frontend/src/pages/Integrations/CloudIntegrationPage/HeroSection/HeroSection.tsx:5

• Draft comment:
  Avoid using inline styles in React components. Consider using external stylesheets, CSS classes, or styled components instead.
• Reason this comment was not posted:
  Comment was not on a valid diff hunk.

Workflow ID: wflow_FtkK3AieLQJm9WQR

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

👍 Looks good to me! Incremental review on 0d5f982 in 22 seconds

More details

• Looked at 214 lines of code in 5 files
• Skipped 0 files when reviewing.
• Skipped posting 3 drafted comments based on config settings.

1. frontend/src/pages/AlertDetails/AlertDetails.tsx:44

• Draft comment:
  The change from string | React.ReactNode | null to string | null for the title prop in BreadCrumbItem reduces flexibility. Ensure this change doesn't break existing functionality that relies on React.ReactNode.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The title prop in BreadCrumbItem is changed from string | React.ReactNode | null to string | null. This change might limit the flexibility of the component if it was intended to support React nodes. However, since the PR description doesn't mention any issues with this change, it seems intentional. It's important to ensure that this change doesn't break any existing functionality that relies on React.ReactNode.

2. frontend/src/pages/Integrations/IntegrationsList.tsx:118

• Draft comment:
  Ensure the custom div with class heading__new-tag for the 'NEW' tag maintains consistent styling and behavior compared to the previous Tag component from antd.
• Reason this comment was not posted:
  Confidence changes required: 30%
  The IntegrationsList component uses a div with the class heading__new-tag to display the 'NEW' tag. This is a change from using the Tag component from antd. The new implementation should be checked for consistent styling and behavior with the rest of the application.

3. frontend/src/pages/Integrations/IntegrationsList.tsx:118

• Draft comment:
  Avoid using inline styles. Consider using CSS classes or styled components instead. This is also applicable in other parts of the code where inline styles are used.
• Reason this comment was not posted:
  Comment was not on a valid diff hunk.

Workflow ID: wflow_QL7jvVULNQBogLM1

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>