Feat/kleros dapp #1755
Feat/kleros dapp #1755
Conversation
WalkthroughThe pull request introduces significant changes across multiple files in the Kleros application. Key modifications include updates to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🪧 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
CodeRabbit Configuration File (
|
❌ Deploy Preview for kleros-v2-testnet-devtools failed. Why did it fail? →
|
❌ Deploy Preview for kleros-v2-testnet failed. Why did it fail? →
|
❌ Deploy Preview for kleros-v2-university failed. Why did it fail? →
|
|
Code Climate has analyzed commit 34f25c7 and detected 30 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
❌ Deploy Preview for kleros-v2-neo failed. Why did it fail? →
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 21
🧹 Outside diff range and nitpick comments (32)
kleros-app/src/App.tsx (2)
1-2: Consider using TypeScript features more effectivelySince this is a
.tsxfile, consider adding type declarations for better type safety and developer experience.-import { createRoot } from "react-dom/client"; +import { Root, createRoot } from "react-dom/client";
1-18: Consider implementing error boundaries and adding documentationThe application could benefit from:
- Implementation of React Error Boundaries for graceful error handling
- JSDoc documentation for the App component
- A more structured layout with proper semantic HTML
Would you like me to provide an example implementation of these improvements?
prettier-config/package.json (1)
6-9: Consider adding peer dependenciesSince this is a shared configuration package, consider adding peer dependencies to explicitly state the compatible versions:
{ "dependencies": { "eslint": "^8.57.1", "prettier": "^3.3.3", "prettier-plugin-solidity": "^1.3.1" }, + "peerDependencies": { + "prettier": "^3.3.3" + }, + "peerDependenciesMeta": { + "prettier": { + "optional": false + } + } }kleros-app/src/lib/atlas/utils/createMessage.ts (1)
3-3: Consider adding JSDoc documentation.Adding JSDoc documentation would improve maintainability by documenting:
- Purpose of the function
- Parameter descriptions
- Return value
- Example usage
+/** + * Creates a SIWE (Sign-In with Ethereum) message for authentication. + * @param address - The Ethereum address of the signer + * @param nonce - A unique nonce for the message + * @param chainId - The chain ID of the network + * @param statement - Optional custom statement (defaults to "Sign In to Kleros with Ethereum.") + * @returns A formatted SIWE message string + */ export const createMessage = (address: `0x${string}`, nonce: string, chainId: number, statement?: string) => {kleros-app/src/lib/atlas/utils/getNonce.ts (4)
3-5: Consider a more descriptive type nameThe type
GetNoncecould be more descriptive, such asGetNonceResponse, to better indicate its role as a response type.-type GetNonce = { +type GetNonceResponse = { nonce: string; };
7-11: Consider using query instead of mutationThe operation fetches a nonce without modifying server state, which aligns more with GraphQL query semantics rather than mutation. Unless there's a specific reason for using mutation (e.g., nonce generation triggers state changes), consider changing to a query operation.
const query = gql` - mutation GetNonce($address: Address!) { + query GetNonce($address: Address!) { nonce(address: $address) } `;
22-24: Remove console.log from production codeConsider using a proper logging service or removing the console.log statement. If needed for debugging, consider using a logging utility that can be configured based on the environment.
13-29: Add input validation and retry mechanismConsider these improvements for better reliability:
- Validate the Ethereum address format before making the request
- Implement a retry mechanism for transient failures
- Add timeout handling
Here's a suggested implementation:
import { isAddress } from 'ethers/lib/utils'; import { retry } from './retry'; // implement or use a retry utility export async function getNonce(client: GraphQLClient, address: string): Promise<string> { if (!isAddress(address)) { throw new Error('Invalid Ethereum address'); } const variables = { address }; return retry( async () => { const response = await client.request<GetNonceResponse>(query, variables); return response.nonce; }, { retries: 3, timeout: 5000, onError: (error) => { const errorMessage = error?.response?.errors?.[0]?.message ?? `Error fetching nonce: ${error?.message ?? 'Unknown error'}`; throw new Error(errorMessage); } } ); }kleros-app/src/lib/atlas/utils/index.ts (2)
1-10: Add JSDoc documentation for the Products enumConsider adding JSDoc documentation to describe the purpose and use case of each product in the enum. This would help other developers understand when to use each product type.
+/** + * Enum representing different Kleros products and modules + */ export enum Products { + /** Court v1 implementation */ CourtV1 = "CourtV1", + /** Court v2 implementation */ CourtV2 = "CourtV2", // ... add documentation for other products
25-32: Consider organizing utilities into sub-modulesThe current structure mixes different types of utilities (authentication, user management, IPFS). Consider organizing these into logical sub-modules for better maintainability:
// auth/index.ts export * from './loginUser'; export * from './getNonce'; export * from './createMessage'; // user/index.ts export * from './addUser'; export * from './fetchUser'; export * from './updateEmail'; export * from './confirmEmail'; // storage/index.ts export * from './uploadToIpfs';Then in this file:
export * from './auth'; export * from './user'; export * from './storage';kleros-app/src/lib/atlas/utils/fetchUser.ts (2)
12-20: Add documentation for authentication requirementsConsider adding JSDoc comments to document whether this query requires authentication and any potential error scenarios.
+/** + * GraphQL query to fetch authenticated user's data. + * Requires: Authentication token in the GraphQL client. + * @throws {Error} When user is not authenticated or server errors occur + */ const query = gql` query GetUser { user {
22-34: Consider adding retry logic and cachingTo improve reliability and performance:
- Implement retry logic for transient failures
- Consider adding response caching to reduce API calls
- Add rate limiting protection
This would make the function more resilient in production environments.
Would you like me to provide an example implementation with these improvements?
kleros-app/src/lib/atlas/utils/addUser.ts (3)
4-8: Consider enhancing the GraphQL mutation definitionThe mutation could benefit from:
- Input validation using GraphQL's built-in validation directives
- A more specific name like
AddAtlasUserto prevent naming conflicts- Explicit definition of the
AddUserSettingsDtotypeconst query = gql` - mutation AddUser($settings: AddUserSettingsDto!) { + mutation AddAtlasUser($settings: AddUserSettingsDto! @validateEmail) { addUser(addUserSettings: $settings) } `;
10-16: Enhance type definitions for better type safetyConsider strengthening the type definitions:
- Add email format validation
- Include additional user metadata in the response
export type AddUserData = { email: string & { __brand: 'Email' }; // Email branded type }; type AddUserResponse = { addUser: { success: boolean; userId?: string; timestamp: string; }; };
18-37: Consider implementing retry logic for network failuresGiven this is a critical user operation, consider implementing retry logic for transient failures.
Example implementation:
import { retry } from '@your-utils/retry'; export function addUser(client: GraphQLClient, userData: AddUserData): Promise<boolean> { return retry( () => executeAddUser(client, userData), { retries: 3, backoff: 'exponential', onRetry: (error) => { // Add monitoring/logging here } } ); }kleros-app/src/lib/atlas/utils/updateEmail.ts (2)
1-8: LGTM! Consider adding email format validation.The GraphQL mutation is well-structured. However, consider adding email format validation at the GraphQL schema level using a custom scalar or directive to ensure valid email formats before they reach the resolver.
1-35: Consider adding rate limiting and security measures.Since this is an authentication-related endpoint:
- Implement rate limiting to prevent abuse
- Add request throttling for the same user
- Consider adding a confirmation step for email changes to prevent unauthorized modifications
- Add audit logging for security-sensitive operations
web/src/components/EnsureAuth.tsx (1)
Line range hint
29-39: Consider enhancing loading state feedback.While the button shows a loading state, consider adding a more descriptive loading message or progress indicator to improve user experience during the signing process.
Example implementation:
return isVerified ? ( children ) : ( + <div className="auth-container"> <Button text="Sign In" onClick={handleClick} disabled={isSigningIn || !address} isLoading={isSigningIn} {...{ className }} /> + {isSigningIn && ( + <span className="loading-text"> + Waiting for wallet signature... + </span> + )} + </div> );web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/EmailVerificationInfo.tsx (1)
Line range hint
89-103: Consider separating concerns and improving state managementThe component currently mixes UI rendering with business logic. Consider:
- Moving the email verification logic to a custom hook
- Extracting the verification status check into a separate function
- Using a loading state while verification is in progress
This would improve maintainability and make the component more testable.
kleros-app/eslint.config.mjs (4)
21-24: Consider extending ignore patterns for build outputs and cachesAdd common build and cache directories to the ignore list to improve linting performance.
{ - ignores: ["src/assets"], + ignores: [ + "src/assets", + "dist", + "build", + "coverage", + "node_modules", + ".cache" + ], },
25-35: Consider adding security-focused ESLint configurationsFor enhanced security coverage, consider extending security-focused configs.
compat.extends( "plugin:react/recommended", "plugin:react-hooks/recommended", "plugin:import/recommended", "plugin:import/react", "plugin:@typescript-eslint/recommended", + "plugin:security/recommended", + "plugin:xss/recommended", "plugin:prettier/recommended", "prettier" )
44-61: Consider updating ECMAScript versionThe current ECMAScript version (2020) could be updated to a more recent version for access to newer language features.
- ecmaVersion: 2020, + ecmaVersion: 2023,
63-73: Consider using 'detect' for React versionInstead of hardcoding the React version, consider using 'detect' to automatically determine the version from package.json.
settings: { react: { - version: "^18.3.1", + version: "detect", },.gitignore (1)
60-61: LGTM! Consider moving the parcel cache entry to a more appropriate section.The addition of
.parcel-cacheis appropriate as these are build artifacts that shouldn't be version controlled. However, for better organization, consider moving this entry to the build output section where similar entries like.next,dist, and.nuxtare located.web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (2)
118-124: Enhance error handling robustnessWhile the added error handling is good, there are a few improvements we can make:
- Add a fallback for error messages
- Use
console.errorfor error logging- Make the error handling flow more consistent
- fileURI = await uploadFile(file, Roles.Evidence).catch((err) => { - console.log(err); - toast.error(`Upload failed: ${err?.message}`, toastOptions); - return null; - }); - if (!fileURI) throw new Error("Error uploading evidence file"); - toast.success("Uploaded successfully!", toastOptions); + fileURI = await uploadFile(file, Roles.Evidence).catch((err) => { + console.error("File upload failed:", err); + toast.error(`Upload failed: ${err?.message || "Unknown error occurred"}`, toastOptions); + return null; + }); + if (fileURI) { + toast.success("Uploaded successfully!", toastOptions); + } else { + throw new Error("Error uploading evidence file"); + }
Line range hint
1-132: Consider implementing an error boundarySince this component handles critical operations like file uploads and contract interactions, consider wrapping it with an error boundary to gracefully handle unexpected errors and prevent the entire UI from crashing.
web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/index.tsx (1)
Line range hint
45-151: Consider splitting component responsibilitiesThe FormContactDetails component handles multiple concerns including form state management, user operations, and email validation. Consider breaking it down into smaller, more focused components:
- A pure form component for email input and validation
- A container component for user operations (create/update)
- A separate hook for form state management
This would improve maintainability and testability.
web/src/context/AtlasProvider.tsx (1)
5-5: Consider avoidingReact.FCand typing props directlyUsing
React.FCis often discouraged because it can introduce unnecessary complexity and may interfere with certain TypeScript features. Instead, you can define your component withoutReact.FCand type the props directly.Apply this diff to refactor the component:
-const AtlasProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => { +interface AtlasProviderProps { + children: React.ReactNode; +} + +const AtlasProvider = ({ children }: AtlasProviderProps) => {kleros-app/src/lib/atlas/utils/uploadToIpfs.ts (2)
15-37: Refactor to use async/await syntax for better readabilityTo improve readability and maintain consistency, consider refactoring the
uploadToIpfsfunction to useasync/awaitsyntax throughout instead of mixing it with.then(). This enhances the clarity of asynchronous operations and error handling.Consider applying this diff:
export async function uploadToIpfs(config: Config, payload: IpfsUploadPayload): Promise<string | null> { const formData = new FormData(); formData.append("file", payload.file, payload.name); formData.append("name", payload.name); formData.append("product", payload.product); formData.append("role", payload.role); - return fetch(`${config.baseUrl}/ipfs/file`, { + const response = await fetch(`${config.baseUrl}/ipfs/file`, { method: "POST", headers: { authorization: `Bearer ${config.authToken}`, }, body: formData, - }).then(async (response) => { - if (!response.ok) { - const error = await response.json().catch(() => ({ message: "Error uploading to IPFS" })); - - if (response.status === 401) throw new AuthorizationError(error.message); - throw new Error(error.message); - } - - return await response.text(); - }); + }); + if (!response.ok) { + const error = await response.json().catch(() => ({ message: "Error uploading to IPFS" })); + if (response.status === 401) throw new AuthorizationError(error.message); + throw new Error(error.message); + } + return await response.text(); }
40-49: Ensure proper subclassing of Error in AuthorizationErrorTo maintain correct prototype chaining and fully leverage the built-in
Errorfunctionalities, explicitly set the prototype in theAuthorizationErrorconstructor. Additionally, setting thenameproperty is redundant since it's automatically assigned.Consider updating the
AuthorizationErrorclass:export class AuthorizationError extends Error { - readonly name = "AuthorizationError" as const; constructor(message: string) { super(message); + Object.setPrototypeOf(this, AuthorizationError.prototype); if (Error.captureStackTrace) { Error.captureStackTrace(this, this.constructor); } } }kleros-app/src/lib/atlas/providers/AtlasProvider.tsx (2)
215-217: Preserve Original Errors When RethrowingWhen rethrowing caught errors, it's better to rethrow the original error to preserve the stack trace and error message.
Apply this diff to each catch block:
In the
addUserfunction:} catch (err: any) { - throw new Error(err); + throw err; } finally {In the
updateEmailfunction:} catch (err: any) { - throw new Error(err); + throw err; } finally {In the
uploadFilefunction:} catch (err: any) { - throw new Error(err); + throw err; } finally {Also applies to: 239-241, 265-267
287-291: Avoid Usingconsole.login Production CodeUsing
console.logfor error handling in production code is discouraged. Consider removing the console log or using a proper logging mechanism.Apply this diff to remove the console log:
} catch (err: any) { - // eslint-disable-next-line - console.log("Confirm Email Error : ", err?.message); return { isConfirmed: false, isTokenExpired: false, isTokenInvalid: false, isError: true }; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (38)
.gitignore(1 hunks)kleros-app/eslint.config.mjs(1 hunks)kleros-app/package.json(1 hunks)kleros-app/src/App.tsx(1 hunks)kleros-app/src/index.html(1 hunks)kleros-app/src/lib/atlas/hooks/useSessionStorage.ts(1 hunks)kleros-app/src/lib/atlas/index.ts(1 hunks)kleros-app/src/lib/atlas/providers/AtlasProvider.tsx(1 hunks)kleros-app/src/lib/atlas/providers/index.ts(1 hunks)kleros-app/src/lib/atlas/utils/addUser.ts(1 hunks)kleros-app/src/lib/atlas/utils/createMessage.ts(2 hunks)kleros-app/src/lib/atlas/utils/fetchUser.ts(1 hunks)kleros-app/src/lib/atlas/utils/getNonce.ts(1 hunks)kleros-app/src/lib/atlas/utils/index.ts(1 hunks)kleros-app/src/lib/atlas/utils/loginUser.ts(1 hunks)kleros-app/src/lib/atlas/utils/updateEmail.ts(1 hunks)kleros-app/src/lib/atlas/utils/uploadToIpfs.ts(1 hunks)kleros-app/src/lib/index.ts(1 hunks)kleros-app/src/utils/index.ts(1 hunks)kleros-app/tsconfig.json(1 hunks)package.json(3 hunks)prettier-config/package.json(1 hunks)web/package.json(1 hunks)web/src/components/EnsureAuth.tsx(2 hunks)web/src/context/AtlasProvider.tsx(1 hunks)web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/EmailVerificationInfo.tsx(2 hunks)web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/index.tsx(3 hunks)web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx(2 hunks)web/src/pages/Resolver/Policy/index.tsx(2 hunks)web/src/pages/Settings/EmailConfirmation/index.tsx(3 hunks)web/src/utils/atlas/addUser.ts(0 hunks)web/src/utils/atlas/fetchUser.ts(0 hunks)web/src/utils/atlas/getNonce.ts(0 hunks)web/src/utils/atlas/index.ts(0 hunks)web/src/utils/atlas/loginUser.ts(0 hunks)web/src/utils/atlas/updateEmail.ts(0 hunks)web/src/utils/atlas/uploadToIpfs.ts(0 hunks)web/src/utils/uploadFormDataToIPFS.ts(0 hunks)
💤 Files with no reviewable changes (8)
- web/src/utils/atlas/addUser.ts
- web/src/utils/atlas/fetchUser.ts
- web/src/utils/atlas/getNonce.ts
- web/src/utils/atlas/index.ts
- web/src/utils/atlas/loginUser.ts
- web/src/utils/atlas/updateEmail.ts
- web/src/utils/atlas/uploadToIpfs.ts
- web/src/utils/uploadFormDataToIPFS.ts
✅ Files skipped from review due to trivial changes (7)
- kleros-app/package.json
- kleros-app/src/index.html
- kleros-app/src/lib/atlas/index.ts
- kleros-app/src/lib/atlas/providers/index.ts
- kleros-app/src/lib/index.ts
- kleros-app/tsconfig.json
- web/src/pages/Settings/EmailConfirmation/index.tsx
🧰 Additional context used
📓 Learnings (1)
web/src/context/AtlasProvider.tsx (1)
Learnt from: Harman-singh-waraich
PR: kleros/kleros-v2#1687
File: web/src/context/AtlasProvider.tsx:225-244
Timestamp: 2024-11-12T04:49:48.060Z
Learning: In `web/src/context/AtlasProvider.tsx`, the `atlasUri` variable comes from environment variables and does not change, so it does not need to be included in dependency arrays.
🔇 Additional comments (22)
prettier-config/package.json (1)
8-8: Verify the impact of Prettier v3 upgrade
The upgrade from Prettier v2 to v3 is a major version bump that includes breaking changes. Please ensure:
- CI/CD pipelines are updated to use Node.js ≥14
- Team is aware of new formatting defaults
- All repositories using this config are tested with the new version
kleros-app/src/lib/atlas/utils/createMessage.ts (1)
Line range hint 3-19: LGTM! Well-structured implementation of SIWE message creation.
The implementation is secure and follows best practices:
- Proper type safety with TypeScript
- Secure message creation using the SIWE standard
- Protection against replay attacks with expiration
- Safe domain/origin handling
kleros-app/src/lib/atlas/hooks/useSessionStorage.ts (2)
22-22: LGTM!
The return type is well-defined and follows React conventions for state hooks.
1-23: Consider security implications for sensitive data storage
Since this hook is used in authentication contexts, be cautious about storing sensitive information in session storage:
- Avoid storing sensitive tokens or PII
- Consider using more secure alternatives like HttpOnly cookies for auth tokens
- Implement storage cleanup on session end
kleros-app/src/lib/atlas/utils/index.ts (1)
12-23: Document roles and verify string values
- Consider adding JSDoc documentation to describe each role's purpose and usage context.
- Verify that the kebab-case string values match the expected values in the system, especially if they're used in URLs or file paths.
+/**
+ * Enum representing different content types and roles in the system
+ * The string values are used in URLs/file paths and should match the backend expectations
+ */
export enum Roles {
+ /** Evidence files uploaded during disputes */
Evidence = "evidence",
+ /** Generic file uploads */
Generic = "generic",
// ... add documentation for other roleskleros-app/src/lib/atlas/utils/updateEmail.ts (1)
10-16: LGTM! Types are well-defined.
The type definitions are clear, properly exported, and accurately represent the data structures for both request and response.
kleros-app/src/lib/atlas/utils/loginUser.ts (2)
9-18: LGTM! Well-structured type definitions
The types are well-defined with proper TypeScript typing, including the use of template literal type for the signature format.
20-38: Consider additional security measures
For authentication endpoints, consider implementing:
- Rate limiting to prevent brute force attacks
- CSRF protection
- Secure headers
- Audit logging for security events
web/src/components/EnsureAuth.tsx (2)
1-8: LGTM! Imports are well-organized and necessary.
All imported modules are utilized effectively in the implementation.
34-34: LGTM! Button handler implementation is correct.
The onClick handler properly uses the memoized callback, and the disabled state is appropriately managed.
package.json (1)
28-29: LGTM! Workspace additions are well-structured
The addition of tsconfig and kleros-app workspaces aligns well with TypeScript adoption and modular development approach.
web/src/pages/Resolver/Policy/index.tsx (3)
8-8: LGTM! Import consolidation improves maintainability
The change to import from @kleros/kleros-app package aligns with the modular architecture approach.
60-60: Verify the role change and remove debug logging
- Please confirm if changing the role from
PolicytoEvidenceis intentional, as this might affect how the file is categorized in the system. - Remove the
console.logstatement in the error handler for production code.
- console.log(err);64-68: LGTM! Improved user feedback with toast notifications
The addition of success and error toast notifications provides better user feedback during the upload process.
web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/EmailVerificationInfo.tsx (1)
8-10: LGTM: Import changes align with centralization strategy
The updated imports properly centralize the Atlas provider functionality and add necessary toast notification capabilities.
kleros-app/eslint.config.mjs (2)
1-19: LGTM! Well-structured setup using modern ESLint flat config
The implementation correctly handles ESM modules and provides backward compatibility through FlatCompat.
101-103: Verify the necessity of disabled TypeScript checks
Disabling no-non-null-assertion and no-explicit-any might lead to type-unsafe code. Consider enabling these rules and addressing the underlying issues.
web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (1)
10-10: LGTM! Good architectural decision.
Moving Roles and useAtlasProvider to @kleros/kleros-app improves code organization and maintainability by centralizing these common utilities.
web/package.json (1)
77-77: LGTM! Please verify workspace setup.
The addition of @kleros/kleros-app as a workspace dependency follows proper conventions.
Please ensure:
- The workspace package is properly initialized and built
- There are no circular dependencies between packages
- The dependency tree remains clean when running
yarn install
web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/index.tsx (1)
9-9: Verify @kleros/kleros-app package dependency
The AtlasProvider import has been moved to @kleros/kleros-app. Ensure this dependency is properly declared in the project's package.json and that the version is compatible with the current implementation.
Also applies to: 20-21
web/src/context/AtlasProvider.tsx (1)
8-8: Verify that REACT_APP_ATLAS_URI is correctly defined
Ensure that import.meta.env.REACT_APP_ATLAS_URI is correctly set in the environment variables and accessible at runtime to prevent potential issues with AtlasProvider initialization.
kleros-app/src/lib/atlas/utils/uploadToIpfs.ts (1)
1-13: Type definitions and imports look good
The import statement and type definitions for IpfsUploadPayload and Config are clear and well-structured, accurately defining the expected data shapes.
web/src/layout/Header/navbar/Menu/Settings/Notifications/FormContactDetails/index.tsx
Show resolved
Hide resolved
|
Closing as too many conflicts in yarn.lock making it dirty. Migrated changes to #1756 on latest |
PR-Codex overview
This PR focuses on restructuring the
kleros-appcodebase by removing several utility files, updating dependencies, and enhancing theAtlasProvider. It also introduces new functionalities for user management and email handling while improving the overall application structure.Detailed summary
web/src/utils/atlas.prettierversion inprettier-config/package.json.isUndefinedutility function inkleros-app/src/utils/index.ts.kleros-app/src/index.html.Appcomponent inkleros-app/src/App.tsx.useSessionStoragehook inkleros-app/src/lib/atlas/hooks/useSessionStorage.ts.getNonce,fetchUser,addUser,updateEmail, andloginUser.createMessageto accept an optionalstatementparameter.uploadToIpfsto includeProductsandRolesenums.AtlasProviderto manage user sessions and interactions with GraphQL.AtlasProviderto use a new configuration structure.Summary by CodeRabbit
New Features
Appas the entry point for the application.useSessionStoragefor managing state synchronized with session storage.AtlasProviderfor user authentication and interactions with the Atlas service.addUser,loginUser, andupdateEmail.Enhancements
EnsureAuthandEmailVerificationInfocomponents to provide better user interaction.Bug Fixes
Chores
.gitignoreandtsconfig.json, for better development experience.