Dashboard: Add provider and initial UI #2943
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThis pull request introduces several changes across multiple files in the Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Outside diff range and nitpick comments (20)
src/content-helper/dashboard-page/components/index.ts (4)
Line range hint
1-8: Enhance JSDoc documentation with additional tags.Consider adding the following JSDoc tags to improve documentation:
@packageto indicate this is part of the wp-parsely package@moduleto specify this is a module file/** * This file is used to export all the components in the dashboard-page folder * * These are common components that are used to build dashboard pages, such as * the main dashboard page, the traffic boost page, and the settings page. * + * @package wp-parsely + * @module content-helper/dashboard-page/components * @since 3.18.0 */
10-15: Add JSDoc documentation for the Page Structure Components section.The section header should be documented with JSDoc to describe the purpose and relationship of these components.
/** * Page Structure Components + * + * Components that provide the basic layout structure for dashboard pages. + * These components work together to create a consistent layout across all pages. + * + * @since 3.18.0 */
17-19: Add JSDoc documentation for the Posts Components section.The section header should be documented with JSDoc to describe the purpose of these components.
/** * Posts Components + * + * Components for displaying and managing post-related data in tables and other formats. + * These components handle the presentation and interaction with post information. + * + * @since 3.18.0 */
20-20: Consider preparing PostsTable for reusability.Based on the PR objectives, the PostsTable component is currently tightly coupled to the Dashboard page but intended for future reuse in the Traffic Boost UI. Consider the following architectural approaches:
- Extract common table functionality into a base component
- Use composition to separate generic table logic from post-specific features
- Implement a provider pattern for data fetching to decouple data management from presentation
Would you like me to provide a detailed implementation plan for any of these approaches?
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (1)
23-33: Consider enhancing type safety and maintainability.The implementation follows good practices with proper localization and component structure. However, here are some suggestions for improvement:
+ // Define query parameters as a constant + const POSTS_QUERY = { + status: 'publish', + per_page: 5, + } as const; + + // Define interface for query parameters + interface PostsQuery { + status: 'publish' | 'draft' | 'private'; + per_page: number; + } + export const DashboardPage = () => { return ( <PageContainer name="dashboard"> <DashboardHeader /> <PageBody> <DashboardHeading>{ __( 'Recent Posts', 'wp-parsely' ) }</DashboardHeading> <p> { __( 'Here's what you've published lately. Let's see if we can improve its performance!', 'wp-parsely' ) } </p> - <PostsTable query={ { - status: 'publish', - per_page: 5, - } } /> + <PostsTable query={POSTS_QUERY} /> </PageBody> </PageContainer> ); };These changes would:
- Make the query parameters more maintainable by defining them as a constant
- Add type safety with TypeScript interfaces
- Make it easier to update the number of posts displayed if needed
src/content-helper/dashboard-page/components/typography-components.tsx (2)
7-15: Enhance type definition documentation.While the type definition is well-structured, its documentation could be improved:
Consider applying these improvements:
/** - * The DashboardHeading component. + * Props for the DashboardHeading component. * * @since 3.18.0 + * @typedef {Object} DashboardHeadingProps + * @property {React.ReactNode} children - The content to be rendered within the heading. + * @property {HeadingProps} [props] - Additional props to be passed to the WordPress Heading component. */
17-35: Improve component documentation and implementation.The component implementation is clean, but there are a few improvements to consider:
- Fix the grammatical error in the JSDoc comment and improve type documentation:
/** * The DashboardHeading component. * - * Can be used to render a heading in the dashboard. and it is a + * Can be used to render a heading in the dashboard. It is a * wrapper around the Heading component from the WordPress components package. * * @since 3.18.0 * - * @param {DashboardHeadingProps} props The component props. + * @param {Object} props - The component props. + * @param {React.ReactNode} props.children - The content to be rendered within the heading. + * @param {HeadingProps} [props.props] - Additional props to be passed to the Heading component. + * @returns {JSX.Element} The rendered heading component. */
- Consider adding prop validation for critical props if needed:
export const DashboardHeading = ( { children, ...props }: DashboardHeadingProps ) => { + if (!children) { + console.warn('DashboardHeading: children prop is required'); + } + return ( <Heading className="parsely-dashboard-header"src/content-helper/dashboard-page/provider.tsx (3)
6-12: Consider enhancing class documentation with singleton pattern details.While the documentation follows WordPress standards and includes the required @SInCE tag, it would be beneficial to document the singleton pattern usage and why it was chosen for this implementation.
Consider adding:
/** * DashboardProvider class for the plugin's dashboard. * * Extends the BaseWordPressProvider to inherit WordPress REST API functionalities. + * This class implements the singleton pattern to ensure only one instance exists + * throughout the application lifecycle. * * @since 3.18.0 */
21-33: Consider adding error handling for edge cases.While the getInstance implementation is correct, consider adding error handling for potential edge cases, such as initialization failures.
Consider:
public static getInstance(): DashboardProvider { if ( ! DashboardProvider.instance ) { + try { DashboardProvider.instance = new DashboardProvider(); + } catch (error) { + console.error('Failed to initialize DashboardProvider:', error); + throw new Error('DashboardProvider initialization failed'); + } } return DashboardProvider.instance; }
35-35: Enhance the TODO comment following WordPress standards.The comment about future methods should follow WordPress standards by ending with a period and providing more specific information about planned functionality.
-// Future dashboard-specific methods will be added here. +// Future dashboard-specific methods will be added here, including post fetching and data manipulation methods.src/content-helper/dashboard-page/pages/dashboard/dashboard.scss (1)
Line range hint
24-24: Convert pixel values to rem unitsAccording to the coding guidelines, dimensions greater than or equal to 3px should use the
to_remfunction. Please update the following lines:- width: 300px; + width: to_rem(300px); - width: 500px; + width: to_rem(500px); - width: 150px; + width: to_rem(150px);Also applies to: 82-82, 89-89
package.json (1)
Line range hint
89-92: Consider documenting the date package's purpose.Consider adding a comment in the
devDependenciesCommentssection to document why the@wordpress/datepackage was added, similar to how other WordPress packages are documented."devDependenciesComments": { "@wordpress/babel-preset-default": "Don't upgrade to v8 or greater until the plugin requires WordPress 6.6. See https://github.com/WordPress/gutenberg/pull/62265/files", - "@wordpress/scripts": "Don't upgrade to v28 or greater until the plugin requires WordPress 6.6. See https://github.com/WordPress/gutenberg/pull/62265/files" + "@wordpress/scripts": "Don't upgrade to v28 or greater until the plugin requires WordPress 6.6. See https://github.com/WordPress/gutenberg/pull/62265/files", + "@wordpress/date": "Required for date formatting in the dashboard components" }src/content-helper/common/base-provider.tsx (2)
48-48: LGTM! Good architectural decision to make these members protected.The change from private to protected access modifiers enhances extensibility while maintaining proper encapsulation. This allows derived classes like
DashboardProviderto manage their API requests effectively.Consider documenting the intended usage patterns for subclasses in the class-level JSDoc, as these protected members are now part of the class's contract with its derivatives.
Also applies to: 111-111
Line range hint
153-171: Consider improving type safety in error handling.The error handling could be made more type-safe:
- } catch ( wpError: any ) { // eslint-disable-line @typescript-eslint/no-explicit-any + } catch ( wpError: unknown ) { + if ( !( wpError instanceof Error ) ) { + return Promise.reject( + new ContentHelperError( + __( 'Unknown error occurred.', 'wp-parsely' ), + ContentHelperErrorCode.Unknown + ) + ); + } + if ( wpError.name === 'AbortError' ) { return Promise.reject( new ContentHelperError( @@ -166,8 +174,8 @@ ); } - let errorMessage = wpError.message; - if ( typeof wpError.message === 'object' && wpError.message[ 0 ].msg ) { + let errorMessage = String(wpError.message); + if ( typeof wpError.message === 'object' && Array.isArray(wpError.message) && wpError.message[0]?.msg ) { errorMessage = wpError.message[ 0 ].msg; }src/UI/class-dashboard-page.php (2)
Line range hint
126-137: Remove demonstration code block.The TODO comment indicates this code block is temporary and should be removed. Since this PR implements the initial dashboard UI, this would be a good time to remove it.
Would you like me to help create a GitHub issue to track the removal of this demonstration code?
Line range hint
171-179: Improve style dependencies management.Instead of enqueueing wp-components separately, add it to the dependencies array of parsely-dashboard-page style. This ensures proper load order and prevents potential styling conflicts.
Apply this diff:
- wp_enqueue_style( 'wp-components' ); - wp_enqueue_style( 'parsely-dashboard-page', $built_assets_url . 'dashboard-page.css', - array(), + array( 'wp-components' ), $asset_info['version'] );src/content-helper/dashboard-page/components/posts-table/component.tsx (2)
62-62: Handle Cases Wherepost.author?.nameMight Be UndefinedWhen rendering
post.author?.name, ensure that it handles cases where the author's name might be undefined to prevent rendering issues.Update the code to provide a fallback when the author's name is not available:
<span className="post-author"> - { post.author?.name } + { post.author?.name || __( 'Unknown author', 'wp-parsely' ) } </span>
37-38: Ensure JSDoc Comments Have Proper Periods and FormattingSome JSDoc comments might be missing periods at the end of parameter descriptions or may not fully adhere to the WordPress JSDoc standards.
Review the JSDoc comments to ensure they end with periods and follow the proper format:
* @param {Object} props The component props * @param {HydratedPost} props.post The post object + * @param {Object} props The component props. + * @param {HydratedPost} props.post The post object.Repeat this process for other JSDoc comments in the file.
Also applies to: 81-86
src/content-helper/common/base-wordpress-provider.tsx (2)
215-215: Simplify condition using optional chainingYou can simplify the condition by using optional chaining:
-if ( post._embedded && post._embedded[ 'wp:term' ] ) { +if ( post._embedded?.[ 'wp:term' ] ) {This makes the code cleaner and more readable.
🧰 Tools
🪛 Biome
[error] 215-215: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
220-220: Simplify condition using optional chainingYou can simplify the condition by using optional chaining:
-if ( post._embedded && post._embedded[ 'wp:featuredmedia' ] ) { +if ( post._embedded?.[ 'wp:featuredmedia' ] ) {This improves code readability.
🧰 Tools
🪛 Biome
[error] 220-220: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (5)
build/content-helper/dashboard-page-rtl.cssis excluded by!build/**build/content-helper/dashboard-page.asset.phpis excluded by!build/**build/content-helper/dashboard-page.cssis excluded by!build/**build/content-helper/dashboard-page.jsis excluded by!build/**package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (13)
package.json(1 hunks)src/UI/class-dashboard-page.php(1 hunks)src/content-helper/common/base-provider.tsx(2 hunks)src/content-helper/common/base-wordpress-provider.tsx(1 hunks)src/content-helper/dashboard-page/components/index.ts(1 hunks)src/content-helper/dashboard-page/components/posts-table/component.tsx(1 hunks)src/content-helper/dashboard-page/components/posts-table/style.scss(1 hunks)src/content-helper/dashboard-page/components/typography-components.tsx(1 hunks)src/content-helper/dashboard-page/dashboard-page.scss(1 hunks)src/content-helper/dashboard-page/pages/dashboard/dashboard.scss(1 hunks)src/content-helper/dashboard-page/pages/dashboard/header-component.tsx(1 hunks)src/content-helper/dashboard-page/pages/dashboard/page-component.tsx(2 hunks)src/content-helper/dashboard-page/provider.tsx(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/content-helper/dashboard-page/pages/dashboard/header-component.tsx
🧰 Additional context used
📓 Path-based instructions (11)
src/UI/class-dashboard-page.php (1)
Pattern **/*.{html,php}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the HTML and PHP code to ensure it is well-structured and adheres to best practices.
- Ensure the code follows WordPress coding standards and is well-documented.
- Confirm the code is secure and free from vulnerabilities.
- Optimize the code for performance, removing any unnecessary elements.
- Validate comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Verify code compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/common/base-provider.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/common/base-wordpress-provider.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/components/index.ts (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/components/posts-table/style.scss (1)
Pattern **/*.{css,scss}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the SCSS code to ensure it is well-structured and adheres to best practices.
- Convert dimensions greater than or equal to 3px to rem units using the to_rem function.
- Utilize variables for sizes and colors defined in src/content-helper/common/css/variables.scss instead of hardcoding values."
src/content-helper/dashboard-page/components/typography-components.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/dashboard-page.scss (1)
Pattern **/*.{css,scss}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the SCSS code to ensure it is well-structured and adheres to best practices.
- Convert dimensions greater than or equal to 3px to rem units using the to_rem function.
- Utilize variables for sizes and colors defined in src/content-helper/common/css/variables.scss instead of hardcoding values."
src/content-helper/dashboard-page/pages/dashboard/dashboard.scss (1)
Pattern **/*.{css,scss}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the SCSS code to ensure it is well-structured and adheres to best practices.
- Convert dimensions greater than or equal to 3px to rem units using the to_rem function.
- Utilize variables for sizes and colors defined in src/content-helper/common/css/variables.scss instead of hardcoding values."
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/provider.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🪛 Biome
src/content-helper/common/base-wordpress-provider.tsx
[error] 215-215: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 220-220: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (14)
src/content-helper/dashboard-page/dashboard-page.scss (1)
4-7: LGTM! Well-structured import section.
The comment block clearly documents the purpose of the import statement, and the modular structure follows best practices.
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (2)
1-11: LGTM! Import structure follows WordPress coding standards.
The imports are well-organized with proper grouping of WordPress and internal dependencies.
Line range hint 13-17: LGTM! Documentation follows WordPress standards.
The JSDoc comment includes the required @SInCE tag with the correct version format.
src/content-helper/dashboard-page/components/typography-components.tsx (1)
4-5: Caution: Usage of experimental WordPress component.
The __experimentalHeading component is marked as experimental, which means it may undergo breaking changes or be removed in future WordPress versions. Consider:
- Using a stable component alternative if available
- Adding a comment documenting the potential risks
- Creating a plan to monitor and update the code when the stable version is released
Let's check if there's a stable alternative:
src/content-helper/dashboard-page/provider.tsx (4)
1-4: LGTM! Clean import structure following WordPress standards.
The import statement is well-organized with proper sectioning and uses relative paths correctly.
13-13: LGTM! Proper class inheritance structure.
The class declaration correctly extends BaseWordPressProvider and follows TypeScript best practices.
14-19: LGTM! Well-documented singleton instance variable.
The private static instance variable is properly declared and documented following WordPress standards.
1-36: Verify the necessity of the singleton pattern.
While the singleton implementation is correct, let's verify if this pattern is the best approach for the dashboard provider. Consider if dependency injection might be more appropriate for better testability and flexibility.
✅ Verification successful
Let me gather more context about how the DashboardProvider is used.
Let me check one more thing about the base provider and other providers' implementations.
Singleton pattern is consistent with codebase architecture
The singleton pattern used in DashboardProvider is appropriate because:
- It follows the established pattern used across all other providers in the codebase (RelatedPosts, TitleSuggestions, SmartLinking, etc.)
- The base
BaseProviderclass is designed for singleton usage with a protected constructor - Providers manage stateful resources (AbortControllers for API requests) that benefit from centralized management
- The implementation ensures consistent request handling and proper cleanup across the dashboard features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other singleton implementations and provider usage patterns
ast-grep --pattern 'class $_ {
private static instance: $_;
public static getInstance(): $_ {
$$$
}
}'
# Search for provider usage to understand the integration points
rg -l "DashboardProvider" --type ts
Length of output: 268
Script:
#!/bin/bash
# Check how DashboardProvider is used in the posts table component
rg -A 5 "DashboardProvider" src/content-helper/dashboard-page/components/posts-table/component.tsx
# Check if there are other providers following similar patterns
rg -l "Provider" --type ts
# Look for base provider implementation
rg -A 10 "class BaseWordPressProvider"
Length of output: 3146
Script:
#!/bin/bash
# Check base provider implementation
cat src/content-helper/common/base-provider.tsx
# Look for other provider implementations to compare patterns
rg -A 5 "class.*Provider extends" --type ts
Length of output: 8873
src/content-helper/dashboard-page/pages/dashboard/dashboard.scss (1)
62-67: LGTM! Box shadow removal looks good.
The addition of box-shadow: none to both the default and hover states is consistent and follows the design requirements.
package.json (1)
41-41: LGTM! Version aligns with other WordPress packages.
The addition of @wordpress/date at version ^5.11.0 is consistent with other WordPress package versions in the dependencies.
src/content-helper/dashboard-page/components/posts-table/component.tsx (4)
243-243: Ensure Proper Usage of Routing in WordPress
Using react-router-dom's Link component may not be fully compatible with WordPress's routing system. Verify that the routing works as expected within the WordPress environment.
Consider using WordPress's built-in routing mechanisms or components from @wordpress/components that handle navigation appropriately.
47-47:
Check the Safety of Rendering User-Provided URLs
Rendering user-provided URLs in the src attribute without validation may pose security risks. Verify that post.thumbnail is a safe URL or implement validation to prevent potential XSS attacks.
Consider using WordPress's esc_url equivalent or ensure the URL comes from a trusted source.
189-189: 🛠️ Refactor suggestion
Avoid Using console.error; Implement Proper Error Handling
Using console.error is not recommended in production code as it may expose internal errors to users and does not align with best practices for error handling in WordPress.
Replace console.error with proper error handling:
- console.error( error ); // eslint-disable-line no-console
+ // Handle the error appropriately, e.g., display a user-friendly message or log the error securely.
+ wp.data.dispatch( 'core/notices' ).createErrorNotice(
+ __( 'An error occurred while fetching posts.', 'wp-parsely' )
+ );This approach uses WordPress's notice system to display an error message to the user.
Likely invalid or redundant comment.
189-189: 🛠️ Refactor suggestion
Ensure Compliance with WordPress Coding Standards for Error Logging
Suppressing ESLint rules with // eslint-disable-line is generally discouraged. Instead, adhere to coding standards by addressing the root cause.
Remove the ESLint suppression and handle the error appropriately:
- console.error( error ); // eslint-disable-line no-console
+ console.error( error );Alternatively, configure your ESLint settings to allow console.error in this context if appropriate.
Likely invalid or redundant comment.
src/content-helper/dashboard-page/components/posts-table/style.scss
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/style.scss
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/style.scss
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/component.tsx
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/component.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (2)
76-82: Add translator context to strings.While the strings are properly internationalized, they lack context for translators. Consider adding translator comments using
translators:docblock.+/* translators: Heading for the section showing recently published posts in the dashboard */ { __( 'Recent Posts', 'wp-parsely' ) } +/* translators: Description text explaining the purpose of the recent posts section */ { __( 'Here's what you've published lately. Let's see if we can improve its performance!', 'wp-parsely' ) }
83-86: Document PostsTable query parameters and consider making them configurable.The hardcoded query parameters could be made more flexible and should be documented.
Consider:
- Making the parameters configurable through props or settings
- Adding JSDoc to document the expected query interface
- Adding error boundaries for better error handling
+/** + * Props for the PostsTable query. + * + * @since 3.18.0 + */ +interface PostsTableQuery { + status: string; + per_page: number; +} +const DEFAULT_POSTS_PER_PAGE = 5; <PostsTable query={ { status: 'publish', - per_page: 5, + per_page: DEFAULT_POSTS_PER_PAGE, } as PostsTableQuery } />src/content-helper/common/css/variables.scss (1)
Line range hint
1-99: Well-structured variables with clear organizationThe file demonstrates excellent organization of variables with:
- Consistent use of rem units for dimensions
- Semantic color naming
- Clear sectioning of variables by purpose
Consider adding a brief comment explaining the purpose of the
.parsely-dashboard-containerclass to improve documentation.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (13)
build/admin-settings-rtl.cssis excluded by!build/**build/admin-settings.asset.phpis excluded by!build/**build/admin-settings.cssis excluded by!build/**build/content-helper/dashboard-page-rtl.cssis excluded by!build/**build/content-helper/dashboard-page.asset.phpis excluded by!build/**build/content-helper/dashboard-page.cssis excluded by!build/**build/content-helper/dashboard-page.jsis excluded by!build/**build/content-helper/dashboard-widget-rtl.cssis excluded by!build/**build/content-helper/dashboard-widget.asset.phpis excluded by!build/**build/content-helper/dashboard-widget.cssis excluded by!build/**build/content-helper/editor-sidebar-rtl.cssis excluded by!build/**build/content-helper/editor-sidebar.asset.phpis excluded by!build/**build/content-helper/editor-sidebar.cssis excluded by!build/**
📒 Files selected for processing (5)
src/UI/class-dashboard-page.php(2 hunks)src/content-helper/common/css/variables.scss(1 hunks)src/content-helper/dashboard-page/dashboard-page.scss(1 hunks)src/content-helper/dashboard-page/pages/dashboard/header-component.tsx(1 hunks)src/content-helper/dashboard-page/pages/dashboard/page-component.tsx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/UI/class-dashboard-page.php
- src/content-helper/dashboard-page/dashboard-page.scss
- src/content-helper/dashboard-page/pages/dashboard/header-component.tsx
🧰 Additional context used
📓 Path-based instructions (2)
src/content-helper/common/css/variables.scss (1)
Pattern **/*.{css,scss}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the SCSS code to ensure it is well-structured and adheres to best practices.
- Convert dimensions greater than or equal to 3px to rem units using the to_rem function.
- Utilize variables for sizes and colors defined in src/content-helper/common/css/variables.scss instead of hardcoding values."
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🔇 Additional comments (2)
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx (1)
4-4: LGTM! Well-organized imports following WordPress standards.
The imports are properly organized with WordPress dependencies separated from internal ones, and components are logically grouped.
Also applies to: 9-10
src/content-helper/common/css/variables.scss (1)
25-25: LGTM: Class selector rename is consistent
The change from .parsely-dashboard-page to .parsely-dashboard-container aligns with the corresponding changes in the PHP codebase.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (4)
src/content-helper/dashboard-page/components/posts-table/component.tsx (2)
40-72: Consider adding error boundary protection for the PostInfo component.The component handles missing data gracefully but could benefit from error boundary protection to prevent rendering failures if the post object is malformed.
+interface PostInfoProps { + post: HydratedPost; +} + -const PostInfo = ( { post }: { post: HydratedPost } ): React.JSX.Element => { +const PostInfo = ( { post }: PostInfoProps ): React.JSX.Element => { + if (!post) { + return <div className="post-table--post-info error"> + {__('Error: Invalid post data', 'wp-parsely')} + </div>; + } + const prettyDate = format( 'M j, o', post.date ?? '' );
88-129: Optimize TablePagination with memoization.The pagination controls could benefit from memoization to prevent unnecessary re-renders, especially for large datasets.
+import { useCallback } from '@wordpress/element'; const TablePagination = ( { currentPage, setCurrentPage, totalPages, onPrevious, onNext, }: { currentPage: number; setCurrentPage: ( value: number ) => void; totalPages: number; onPrevious: () => void; onNext: () => void; } ): React.JSX.Element => { + const handleChange = useCallback(( value ) => { + let selectedPage = parseInt( value ?? '1', 10 ); + if ( selectedPage > totalPages ) { + selectedPage = totalPages; + } else if ( selectedPage < 1 ) { + selectedPage = 1; + } + setCurrentPage( selectedPage ); + }, [totalPages, setCurrentPage]); return ( <div className="post-table--pagination-controls"> <div className="page-selector"> <span>{ __( 'Page', 'wp-parsely' ) }</span> <NumberControl value={ currentPage } - onChange={ ( value ) => { - let selectedPage = parseInt( value ?? '1', 10 ); - if ( selectedPage > totalPages ) { - selectedPage = totalPages; - } else if ( selectedPage < 1 ) { - selectedPage = 1; - } - setCurrentPage( selectedPage ); - } } + onChange={ handleChange }src/content-helper/common/base-wordpress-provider.tsx (2)
99-99: Consider using a more specific type for QueryParams.Using
Record<string, any>reduces type safety. Consider defining a more specific interface with known query parameters for better type checking and code maintainability.-export type QueryParams = Record<string, any>; +export type QueryParams = { + page?: number; + per_page?: number; + search?: string; + after?: string; + author?: number; + status?: string; + // Add other known query parameters +};
150-161: Consider more specific error typing.The catch block uses
anytype for the error. Consider creating a specific error type for WordPress API errors to improve type safety and error handling.-} catch ( wpError: any ) { +interface WordPressApiError extends Error { + code: string; + data?: { + status: number; + }; +} +} catch ( wpError: WordPressApiError ) {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (4)
build/content-helper/dashboard-page-rtl.cssis excluded by!build/**build/content-helper/dashboard-page.asset.phpis excluded by!build/**build/content-helper/dashboard-page.cssis excluded by!build/**build/content-helper/dashboard-page.jsis excluded by!build/**
📒 Files selected for processing (4)
src/content-helper/common/base-wordpress-provider.tsx(1 hunks)src/content-helper/dashboard-page/components/posts-table/component.tsx(1 hunks)src/content-helper/dashboard-page/components/posts-table/style.scss(1 hunks)src/content-helper/dashboard-page/pages/dashboard/dashboard.scss(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/content-helper/dashboard-page/components/posts-table/style.scss
- src/content-helper/dashboard-page/pages/dashboard/dashboard.scss
🧰 Additional context used
📓 Path-based instructions (2)
src/content-helper/common/base-wordpress-provider.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🪛 Biome (1.9.4)
src/content-helper/common/base-wordpress-provider.tsx
[error] 215-215: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 220-220: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (3)
src/content-helper/common/base-wordpress-provider.tsx (3)
24-92: LGTM! Well-structured type definitions.
The type definitions are comprehensive and well-documented with JSDoc comments. The embedded data structure is thoroughly typed, which will help catch potential type-related issues at compile time.
247-263: LGTM! Well-implemented post fetching methods.
The getPosts and getPost methods are well-implemented with proper error handling and data hydration. The methods correctly handle the WordPress REST API response format and embedded data.
Also applies to: 275-288
303-315: LGTM! Generic REST API fetching method.
The fetchFromRestApi method provides a flexible and type-safe way to interact with any WordPress REST API endpoint. The default options and method handling are well-implemented.
src/content-helper/dashboard-page/pages/dashboard/page-component.tsx
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/style.scss
Outdated
Show resolved
Hide resolved
src/content-helper/dashboard-page/components/posts-table/component.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
src/content-helper/common/base-provider.tsx(3 hunks)src/content-helper/common/base-wordpress-provider.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/content-helper/common/base-provider.tsx
🧰 Additional context used
📓 Path-based instructions (1)
src/content-helper/common/base-wordpress-provider.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🪛 Biome (1.9.4)
src/content-helper/common/base-wordpress-provider.tsx
[error] 215-215: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 220-220: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (1)
src/content-helper/common/base-wordpress-provider.tsx (1)
214-223: 🛠️ Refactor suggestion
Improve null safety with optional chaining.
To prevent potential runtime errors and enhance readability, consider using optional chaining in the conditions.
Apply this diff to refactor the code:
if ( post._embedded && post._embedded[ 'wp:term' ] ) {
+ if ( post._embedded?.[ 'wp:term' ] ) {
[ categories, tags ] = post._embedded[ 'wp:term' ];
}
if ( post._embedded && post._embedded[ 'wp:featuredmedia' ] ) {
+ if ( post._embedded?.[ 'wp:featuredmedia' ]?.[ 0 ] ) {
const featuredMedia = post._embedded[ 'wp:featuredmedia' ][ 0 ];
thumbnail = featuredMedia?.media_details.sizes.thumbnail.source_url;
}🧰 Tools
🪛 Biome (1.9.4)
[error] 215-215: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 220-220: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
src/content-helper/dashboard-page/dashboard-page.tsx (1)
Line range hint
45-77: Consider using WordPress APIs for menu management.The current implementation directly manipulates DOM elements for menu highlighting and link modification. This approach might be fragile if WordPress admin menu structure changes.
Consider:
- Using WordPress's built-in menu management functions if available.
- Creating a custom hook to encapsulate menu manipulation logic.
- Adding error handling for cases where selectors don't match.
Example implementation:
const useWordPressMenu = (location: Location) => { useEffect(() => { try { // First link modification const firstLink = document.querySelector( '#toplevel_page_parsely-dashboard-page .wp-submenu li a.wp-first-item' ); if (firstLink) { firstLink.setAttribute( 'href', window.location.pathname + window.location.search + '#/' ); } // Menu highlighting const submenuItems = document.querySelectorAll( '#toplevel_page_parsely-dashboard-page .wp-submenu li' ); submenuItems.forEach((item) => { const link = item.querySelector('a'); const hashPath = link?.getAttribute('href')?.split('#')[1]; if (hashPath === location.pathname) { item.classList.add('current'); link?.blur(); } else { item.classList.remove('current'); } }); } catch (error) { console.error('Failed to update WordPress menu:', error); } }, [location]); };src/content-helper/dashboard-page/components/posts-table/component.tsx (2)
44-53: Enhance accessibility for post thumbnailsThe thumbnail section needs proper ARIA attributes and keyboard navigation support.
Apply this diff to improve accessibility:
- <div className="thumbnail"> + <div className="thumbnail" role="img" aria-label={ __( 'Post thumbnail', 'wp-parsely' ) }> { post.thumbnail ? ( - <img src={ post.thumbnail } alt={ post.title.rendered } /> + <img + src={ post.thumbnail } + alt={ post.title.rendered } + loading="lazy" + /> ) : ( - <div className="icon-container"> + <div className="icon-container" aria-hidden="true"> <Icon icon={ page } size={ 24 } /> </div> ) } </div>
107-116: Improve number input validation and user feedbackThe current validation silently corrects invalid input. Consider providing feedback to users when they enter invalid values.
onChange={ ( value ) => { + const newValue = value?.trim() ?? '1'; + if (!/^\d+$/.test(newValue)) { + // Invalid input - not a number + return; + } - let selectedPage = parseInt( value ?? '1', 10 ); + let selectedPage = parseInt( newValue, 10 ); if ( selectedPage > totalPages ) { selectedPage = totalPages; + // Consider showing a toast notification here } else if ( selectedPage < 1 ) { selectedPage = 1; + // Consider showing a toast notification here } setCurrentPage( selectedPage ); } }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (5)
build/content-helper/dashboard-page-rtl.cssis excluded by!build/**build/content-helper/dashboard-page.asset.phpis excluded by!build/**build/content-helper/dashboard-page.cssis excluded by!build/**build/content-helper/dashboard-page.jsis excluded by!build/**package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
package.json(3 hunks)src/content-helper/dashboard-page/components/posts-table/component.tsx(1 hunks)src/content-helper/dashboard-page/components/posts-table/style.scss(1 hunks)src/content-helper/dashboard-page/dashboard-page.tsx(1 hunks)src/content-helper/dashboard-page/pages/dashboard/page-component.tsx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- package.json
- src/content-helper/dashboard-page/components/posts-table/style.scss
- src/content-helper/dashboard-page/pages/dashboard/page-component.tsx
🧰 Additional context used
📓 Path-based instructions (2)
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/dashboard-page/dashboard-page.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🔇 Additional comments (3)
src/content-helper/dashboard-page/dashboard-page.tsx (2)
Line range hint 1-93: Well-structured component with proper documentation.
The component follows WordPress coding standards with proper JSDoc comments, @SInCE tags, and clear organization of imports and component structure.
28-28: Verify React Router version compatibility.
The removal of v7 properties (v7_relativeSplatPath and v7_startTransition) might affect routing behavior. Please ensure this change is intentional and compatible with your React Router version.
✅ Verification successful
Router configuration is correct and compatible
The removal of v7 properties is intentional as the codebase is using react-router-dom v7.0.1 from devDependencies. The Router component is properly configured as a HashRouter (aliased as Router) and follows the standard v7 implementation pattern.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check React Router version and related configurations
cat package.json | jq '.dependencies["react-router-dom"]'
Length of output: 64
Script:
#!/bin/bash
# Let's check if react-router-dom might be in devDependencies or peerDependencies
cat package.json | jq '.devDependencies["react-router-dom"], .peerDependencies["react-router-dom"]'
# Also search for Router imports to understand the routing setup
rg -l "import.*Router.*from" --type ts --type tsx
# Check the actual Router usage pattern
rg "Router" --type ts --type tsx -A 2 -B 2
Length of output: 266
Script:
#!/bin/bash
# Search for Router imports and usage without file type restrictions
rg -l "import.*Router.*from"
# Check the actual Router usage pattern with context
rg "Router" -A 2 -B 2
# Let's also check if there are any migration guides or documentation
fd README
Length of output: 60498
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
138-153: Implement View and Edit action handlers
The View and Edit menu items currently only close the dropdown without performing any action. The component should accept the post object and implement proper navigation.
There was a problem hiding this comment.
I've left a minor comment but this looks good to me and approving it.
Thank you for working on this!
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
173-173: Add type constraints for the query parameter.The query parameter accepts any properties defined in QueryParams, but some might not be relevant for this context.
Consider creating a specific type for the allowed query parameters:
type PostsTableQueryParams = Pick<QueryParams, 'per_page' | 'status' | 'author'>; export const PostsTable = ({ query = {} }: { query?: PostsTableQueryParams }): React.JSX.Element => {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (4)
build/content-helper/dashboard-page-rtl.cssis excluded by!build/**build/content-helper/dashboard-page.asset.phpis excluded by!build/**build/content-helper/dashboard-page.cssis excluded by!build/**build/content-helper/dashboard-page.jsis excluded by!build/**
📒 Files selected for processing (2)
src/content-helper/dashboard-page/components/posts-table/component.tsx(1 hunks)src/content-helper/dashboard-page/components/posts-table/style.scss(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/content-helper/dashboard-page/components/posts-table/style.scss
🧰 Additional context used
📓 Path-based instructions (1)
src/content-helper/dashboard-page/components/posts-table/component.tsx (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
Description
This PR introduces the dashboard provider, to facilitate the communication from the front-end with the WordPress REST API.
As a good way to test and understand the requirements for this provider, I also implemented an initial version of the main dashboard page, that contains a table listing all the recent posts.
I did try to implement some of the code with reusability in mind, however some components such as the PostsTable component, while technically reusable, is still too tied to the Dashboard page. We can make it more generic once we start working on the Traffic Boost UI.
Motivation and context
How has this been tested?
Tested locally.
Screenshots (if appropriate)
Screen.Recording.2024-11-15.at.09.25.52.mov
Summary by CodeRabbit
Release Notes
New Features
PostsTablecomponent for displaying posts within the dashboard.DashboardHeadingcomponent for improved header display.DashboardProviderclass for managing dashboard-specific functionalities.Bug Fixes
Documentation
Chores