Atlas integration for file uploads to IPFS #1687
Conversation
WalkthroughThe changes involve updates to multiple environment configuration files, specifically modifying the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant AtlasProvider
participant IPFS
participant GraphQL
User->>AtlasProvider: uploadFile(file)
AtlasProvider->>GraphQL: getPreSignedUrl(filename)
GraphQL-->>AtlasProvider: return presigned URL
AtlasProvider->>IPFS: PUT request to upload file
IPFS-->>AtlasProvider: return upload status
AtlasProvider-->>User: return upload result
Possibly related PRs
Suggested labels
Suggested reviewers
🪧 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 (
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (1)
web/src/utils/atlas/uploadToIpfs.ts (1)
33-37: Consider making theappnameargument configurable.The
presignedUrlQuerymutation is correctly defined with the requiredfilenameargument. However, theappnameargument is hardcoded toKlerosCourt, which might not be flexible for other use cases.Consider making the
appnameargument configurable by passing it as a variable to thegetPreSignedUrlfunction. This will make the function more reusable for other applications.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (7)
- web/netlify/functions/uploadToIPFS.ts (0 hunks)
- web/netlify/middleware/authMiddleware.ts (0 hunks)
- web/src/context/AtlasProvider.tsx (7 hunks)
- web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (3 hunks)
- web/src/pages/Resolver/Policy/index.tsx (2 hunks)
- web/src/utils/atlas/index.ts (1 hunks)
- web/src/utils/atlas/uploadToIpfs.ts (1 hunks)
Files not reviewed due to no reviewable changes (2)
- web/netlify/functions/uploadToIPFS.ts
- web/netlify/middleware/authMiddleware.ts
Additional comments not posted (12)
web/src/utils/atlas/index.ts (1)
7-7: LGTM!The export statement is correctly implemented and is consistent with the other export statements in the file. Exporting the
uploadToIpfsmodule enhances the functionality of theatlasutility by making it available for import in other parts of the application, contributing to the modularity and reusability of the codebase.web/src/utils/atlas/uploadToIpfs.ts (2)
6-31: LGTM!The
uploadToIpfsfunction is well-implemented and handles the file upload to IPFS using a presigned URL correctly. It uses thetoastlibrary effectively to display upload progress and error messages. The function returns the IPFS CID of the uploaded file on successful upload, which is the expected behavior.
43-70: LGTM!The
getPreSignedUrlfunction is well-implemented and fetches the presigned URL for uploading a file to IPFS correctly using a GraphQL mutation. It uses thetoastlibrary effectively to display error messages. The function returns the presigned URL on successful response, which is the expected behavior.web/src/pages/Resolver/Policy/index.tsx (1)
Line range hint
54-67: LGTM! The refactor improves the code quality and aligns with the new upload mechanism.The changes simplify the file upload process by directly using the
uploadFilemethod from theAtlasProvidercontext. This enhances the clarity and efficiency of the code while maintaining the core functionality of updating thedisputeDatawith the newpolicyURI.Please ensure that the
uploadFilemethod is correctly implemented in theAtlasProvidercontext to handle the file upload to IPFS and return the appropriatecid.Run the following script to verify the
uploadFilemethod:Verification successful
Verification Successful: The
uploadFilemethod is correctly implemented in theAtlasProvidercontext.The method handles file uploads to IPFS and returns the appropriate
cid. It is well-integrated and used consistently across the codebase.
- Located in
web/src/context/AtlasProvider.tsx.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of the `uploadFile` method in the `AtlasProvider` context. # Test: Search for the `uploadFile` method declaration and implementation. # Expect: The method should handle the file upload to IPFS and return the `cid`. ast-grep --lang typescript --pattern $'const AtlasProvider = ({ children }: Props) => { $$$ const uploadFile = async (file: File) => { $$$ return cid; }; $$$ }'Length of output: 177
Script:
#!/bin/bash # Description: Search for the `uploadFile` method across the entire codebase to verify its implementation. # Test: Search for the `uploadFile` method declaration and implementation. # Expect: The method should handle the file upload to IPFS and return the `cid`. rg 'uploadFile' -A 10 --type=tsLength of output: 7821
web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (4)
10-10: LGTM!The import statement for the
useAtlasProviderhook is correct and follows the proper syntax. It will likely be used to access theuploadFilefunction for uploading files to IPFS.
64-64: LGTM!The destructuring assignment for the
uploadFilefunction from theuseAtlasProviderhook is correct and follows the proper syntax. It will likely be used to handle file uploads to IPFS.
104-105: LGTM!The changes to the
constructEvidencefunction to accept theuploadFilefunction as a parameter align with the AI-generated summary. Declaring thefileURIvariable with an initial value ofnullis a good practice, as it explicitly sets the initial value and avoids potential undefined behavior.
108-109: LGTM!The changes to call the
uploadFilefunction with thefileargument and assign the result to thefileURIvariable align with the AI-generated summary. Throwing an error if thefileURIis falsy ensures that the evidence submission process is halted if the file upload fails, and the error message clearly communicates the reason for the error.web/src/context/AtlasProvider.tsx (4)
16-16: LGTM!The import statement for
uploadToIpfsis correct and necessary for using the function in this file.
30-30: LGTM!The changes to the
IAtlasProviderinterface and theAtlasProvidercomponent are consistent and necessary for implementing the file upload functionality in the context.Also applies to: 36-36, 55-55
130-131: LGTM!The change to the
userExistsmemoized value is correct and necessary for determining if a user exists based on the presence of the
207-231: LGTM!The implementation of the
uploadFilemethod in theAtlasProvidercomponent is correct and follows the necessary steps for handling file uploads to IPFS. The method correctly checks for user verification and address, sets theisUploadingFilestate variable to track the upload status, handles the response from theuploadToIpfsfunction, and includes proper error handling and logging.
jaybuidl
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
web/src/pages/Resolver/Policy/index.tsx (1)
61-64: Approve changes with a suggestion for improved error handling.The updated
handleFileUploadfunction successfully integrates the newuploadFilemethod from AtlasProvider, simplifying the upload process. The use ofRoles.Policyadds structure to the upload functionality.However, consider enhancing the error handling to provide more specific error messages to the user.
Consider updating the error handling as follows:
uploadFile(file, Roles.Policy) .then(async (cid) => { if (!cid) return; setDisputeData({ ...disputeData, policyURI: cid }); }) - .catch((err) => console.log(err)) + .catch((err) => { + console.error("Policy upload failed:", err); + toast.error("Failed to upload policy. Please try again.", toastOptions); + }) .finally(() => setIsPolicyUploading(false));This change will provide more informative feedback to the user in case of upload failures.
web/src/context/AtlasProvider.tsx (1)
237-237: Useconsole.errorinstead ofconsole.logfor error messages.When logging errors, it's best practice to use
console.errorto clearly differentiate error messages from standard logs.Apply this diff to update the error logging:
- console.log("Upload File Error : ", err?.message); + console.error("Upload File Error : ", err?.message);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (11)
- web/.env.devnet-neo.public (1 hunks)
- web/.env.devnet-university.public (1 hunks)
- web/.env.devnet.public (1 hunks)
- web/.env.local.public (1 hunks)
- web/.env.mainnet-neo.public (1 hunks)
- web/.env.testnet.public (1 hunks)
- web/src/context/AtlasProvider.tsx (8 hunks)
- web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (3 hunks)
- web/src/pages/Resolver/Policy/index.tsx (2 hunks)
- web/src/utils/atlas/index.ts (1 hunks)
- web/src/utils/atlas/uploadToIpfs.ts (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- web/.env.local.public
🧰 Additional context used
📓 Learnings (1)
web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (2)
Learnt from: Harman-singh-waraich PR: kleros/kleros-v2#1687 File: web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx:67-84 Timestamp: 2024-10-08T16:23:56.291Z Learning: In the `submitEvidence` function of the SubmitEvidenceModal component, the try-catch block is specifically designed to handle errors from the `constructEvidence` function, which may throw an Error if file upload fails. This ensures that the file is successfully uploaded before proceeding with evidence submission and transaction signing.Learnt from: Harman-singh-waraich PR: kleros/kleros-v2#1687 File: web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx:67-84 Timestamp: 2024-09-12T14:45:48.019Z Learning: In the `submitEvidence` function of the SubmitEvidenceModal component, the try-catch block is specifically designed to handle errors from the `constructEvidence` function, which may throw an Error if file upload fails. This ensures that the file is successfully uploaded before proceeding with evidence submission and transaction signing.
🔇 Additional comments (13)
web/src/utils/atlas/index.ts (1)
8-8: LGTM! Verify the implementation ofuploadToIpfs.The addition of the
uploadToIpfsexport aligns with the PR objectives of integrating IPFS upload functionality. This change looks good and should make the IPFS upload function available for use in other parts of the application.To ensure the correctness of this change, let's verify the implementation of the
uploadToIpfsmodule:This script will help us confirm that the
uploadToIpfsmodule is properly implemented and used in the codebase.✅ Verification successful
Need to Re-verify the Usage of
uploadToIpfsThe previous search for
uploadToIpfsusage failed due to an unrecognized file type. Let's rerun the search without specifying file types to ensure all usages are captured.
uploadToIpfsis correctly implemented and properly utilized within the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of the uploadToIpfs module # Test 1: Check if the uploadToIpfs.ts file exists echo "Checking if uploadToIpfs.ts exists:" fd --type f "uploadToIpfs.ts" web/src/utils/atlas # Test 2: Display the content of uploadToIpfs.ts if it exists echo "Content of uploadToIpfs.ts (if it exists):" fd --type f "uploadToIpfs.ts" web/src/utils/atlas --exec cat {} # Test 3: Check for any usage of uploadToIpfs in the codebase echo "Checking for usage of uploadToIpfs in the codebase:" rg --type typescript "uploadToIpfs" web/srcLength of output: 1955
Script:
#!/bin/bash # Description: Re-verify usage of uploadToIpfs in the codebase echo "Searching for usage of 'uploadToIpfs' in TypeScript files:" rg "uploadToIpfs" web/src --glob "*.ts" --glob "*.tsx"Length of output: 514
web/.env.testnet.public (1)
6-6: LGTM. Verify Atlas service interaction and update documentation if needed.The change to
REACT_APP_ATLAS_URIaligns with the PR objectives of integrating IPFS upload logic into the AtlasProvider. However, please ensure the following:
- Verify that removing
/graphqlfrom the URI doesn't break existing API calls to the Atlas service.- Update any relevant documentation that might reference the old URI structure.
- Confirm that this change is consistent across all environment files (e.g., production, development) if applicable.
To verify the consistency of this change across environment files, run the following script:
web/.env.devnet.public (1)
7-7: LGTM. Verify API request construction and update documentation.The change to
REACT_APP_ATLAS_URIlooks good and aligns with the PR objectives. However, please ensure the following:
- Verify that all API requests in the application code have been updated to append the necessary endpoints (e.g.,
/graphqlif still required) when constructing URLs.- Update any relevant documentation that references the Atlas URI to reflect this change.
To verify the impact of this change, you can run the following script:
This script will help identify areas of the code that might need adjustment due to the ATLAS_URI change.
✅ Verification successful
Verification Successful.
The updates to
REACT_APP_ATLAS_URIhave been correctly implemented. API requests are appropriately constructed with the/graphqlendpoint, ensuring continued functionality.
- Confirmed that
REACT_APP_ATLAS_URIis utilized inAtlasProvider.tsxto initialize theGraphQLClientwith/graphql.- No Atlas-related API calls were found that require further adjustments.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential issues with Atlas URI usage # Search for usages of REACT_APP_ATLAS_URI echo "Searching for REACT_APP_ATLAS_URI usage:" rg "REACT_APP_ATLAS_URI" --type ts --type tsx # Search for hardcoded '/graphql' endpoints echo "Searching for hardcoded '/graphql' endpoints:" rg "/graphql" --type ts --type tsx # Search for Atlas-related API calls echo "Searching for Atlas-related API calls:" rg "atlas.*api|api.*atlas" --type ts --type tsxLength of output: 499
Script:
#!/bin/bash # Description: Check for potential issues with Atlas URI usage using correct file types # Search for usages of REACT_APP_ATLAS_URI echo "Searching for REACT_APP_ATLAS_URI usage:" rg "REACT_APP_ATLAS_URI" --type typescript --type typescriptreact # Search for hardcoded '/graphql' endpoints echo "Searching for hardcoded '/graphql' endpoints:" rg "/graphql" --type typescript --type typescriptreact # Search for Atlas-related API calls echo "Searching for Atlas-related API calls:" rg "atlas.*api|api.*atlas" --type typescript --type typescriptreactLength of output: 580
Script:
#!/bin/bash # Description: Check for potential issues with Atlas URI usage by targeting specific file extensions # Search for usages of REACT_APP_ATLAS_URI in .ts and .tsx files echo "Searching for REACT_APP_ATLAS_URI usage in .ts and .tsx files:" rg "REACT_APP_ATLAS_URI" -g "*.ts" -g "*.tsx" # Search for hardcoded '/graphql' endpoints in .ts and .tsx files echo "Searching for hardcoded '/graphql' endpoints in .ts and .tsx files:" rg "/graphql" -g "*.ts" -g "*.tsx" # Search for Atlas-related API calls in .ts and .tsx files echo "Searching for Atlas-related API calls in .ts and .tsx files:" rg "atlas.*api|api.*atlas" -g "*.ts" -g "*.tsx"Length of output: 6001
web/.env.mainnet-neo.public (1)
8-8: Approve change, but verify configuration and impact.The modification of
REACT_APP_ATLAS_URIaligns with the PR objectives for integrating IPFS upload logic. However, there are a couple of points to consider:
Using a localhost URL (
http://localhost:3000) in a mainnet configuration file is unusual and potentially problematic. Please verify if this is intentional or if it should be replaced with the actual production URL.The removal of the
/graphqlendpoint from the URI might affect how the application interacts with the GraphQL service. Ensure that this change is consistent with the updates in theAtlasProviderand other components that use this URI.To verify the impact of this change, please run the following script:
This script will help identify areas of the codebase that might be affected by the URI change, allowing you to ensure that all GraphQL and Atlas-related functionality is updated accordingly.
✅ Verification successful
Change verified; no issues found.
The modification of
REACT_APP_ATLAS_URIhas been reviewed, and all usages ofatlasUriin the codebase are consistent with the removal of/graphql. TheGraphQLClientis correctly configured by appending/graphqlto the base URI, ensuring proper interactions with the GraphQL service.However, using a localhost URL (
http://localhost:3000) in a mainnet configuration is unusual and should be verified to ensure it’s intentional and appropriate for the deployment environment.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for GraphQL endpoint usage in the codebase # Search for GraphQL-related imports and usage echo "Searching for GraphQL-related code:" rg --type typescript --type javascript 'import.*from.*@apollo/client' -A 5 rg --type typescript --type javascript 'useQuery|useMutation|gql`' -A 5 # Search for direct usage of REACT_APP_ATLAS_URI echo "Searching for REACT_APP_ATLAS_URI usage:" rg --type typescript --type javascript 'process\.env\.REACT_APP_ATLAS_URI' -A 5 # Search for Atlas-related components or providers echo "Searching for Atlas-related components:" rg --type typescript --type javascript 'AtlasProvider|useAtlas' -A 5Length of output: 704
Script:
#!/bin/bash # Description: Check for GraphQL endpoint usage in the codebase echo "Searching for GraphQL-related code:" rg 'import\s+.*\s+from\s+["@'\'']@apollo/client["@'\'']' -A 5 --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' rg 'useQuery|useMutation|gql`' -A 5 --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' echo "Searching for REACT_APP_ATLAS_URI usage:" rg 'process\.env\.REACT_APP_ATLAS_URI' -A 5 --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' echo "Searching for Atlas-related components:" rg 'AtlasProvider|useAtlas' -A 5 --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx'Length of output: 40120
Script:
#!/bin/bash # Description: Verify how `atlasUri` is used within the codebase to assess the impact of removing `/graphql` from the URI. echo "Searching for usages of `atlasUri` variable:" rg 'atlasUri' --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' -A 5 echo "Checking GraphQL client configurations for potential URI concatenations:" rg 'ApolloClient' --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' -A 10 rg 'new ApolloClient' --glob '*.ts' --glob '*.tsx' --glob '*.js' --glob '*.jsx' -A 10Length of output: 2235
web/.env.devnet-neo.public (1)
8-8: LGTM. Verify Atlas service interaction.The change to
REACT_APP_ATLAS_URIaligns with the PR objectives of refactoring the file upload functionality and integrating IPFS upload logic into theAtlasProvider.Please ensure that this change doesn't negatively impact the application's interaction with the Atlas service. Run the following script to verify the usage of
REACT_APP_ATLAS_URIacross the codebase:This will help identify any places where the removal of
/graphqlmight require additional adjustments.web/.env.devnet-university.public (1)
8-8: LGTM. Verify impact and update documentation if needed.The change to
REACT_APP_ATLAS_URIaligns with the PR objectives of integrating IPFS upload logic into the AtlasProvider. However, please ensure the following:
- Verify that all parts of the codebase that rely on this URI have been updated accordingly.
- Check if this change affects any API calls or GraphQL queries in the application.
- Update any relevant documentation that references the Atlas URI.
To help verify the impact of this change, you can run the following script:
This script will help identify any places in the codebase that might need to be updated due to this change.
✅ Verification successful
Please run the following updated script to verify the changes:
This script adjusts the search by specifying file patterns using the
--globoption instead of the--typeflag, which should prevent the "unrecognized file type" error and ensure all relevant files are included in the search.
Verified. No issues found.
The update to
REACT_APP_ATLAS_URIhas been successfully integrated, and no hardcoded references to the old URI (http://localhost:3000/graphql) were detected in the codebase. All existing usages ofREACT_APP_ATLAS_URIcorrectly reference the environment variable.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for occurrences of REACT_APP_ATLAS_URI in the codebase # Test: Look for usages of REACT_APP_ATLAS_URI echo "Searching for REACT_APP_ATLAS_URI usage:" rg "REACT_APP_ATLAS_URI" --type ts --type tsx --type js --type jsx # Test: Look for hardcoded references to the old URI echo "Searching for hardcoded references to the old URI:" rg "http://localhost:3000/graphql" --type ts --type tsx --type js --type jsxLength of output: 401
Script:
# #!/bin/bash # Description: Search for occurrences of REACT_APP_ATLAS_URI in the codebase # Test: Look for usages of REACT_APP_ATLAS_URI echo "Searching for REACT_APP_ATLAS_URI usage:" rg "REACT_APP_ATLAS_URI" --glob "*.ts" --glob "*.tsx" --glob "*.js" --glob "*.jsx" # Test: Look for hardcoded references to the old URI echo "Searching for hardcoded references to the old URI:" rg "http://localhost:3000/graphql" --glob "*.ts" --glob "*.tsx" --glob "*.js" --glob "*.jsx"Length of output: 609
web/src/pages/Resolver/Policy/index.tsx (2)
8-8: LGTM: New imports for AtlasProvider integration.The new import statements for
useAtlasProviderandRolesare correctly added and necessary for the updated file upload implementation using AtlasProvider.Also applies to: 10-10
55-55: LGTM: AtlasProvider hook integration.The
uploadFilefunction is correctly extracted from the AtlasProvider context using theuseAtlasProviderhook. This is a good use of the new context for file uploads.web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (5)
10-10: ImportinguseAtlasProviderModuleThe import statement correctly imports
useAtlasProviderfrom"context/AtlasProvider", which is essential for accessing theuploadFilefunction needed for file uploads.
12-12: ImportingRolesEnumThe
Rolesenum is imported from"utils/atlas"and is appropriately used to specify the role during file upload in theconstructEvidencefunction.
65-65: ExtractinguploadFilefromuseAtlasProviderDestructuring
uploadFilefromuseAtlasProviderallows the component to utilize the file upload functionality provided by the Atlas context effectively.
68-86: Enhanced Error Handling insubmitEvidenceFunctionThe addition of the
try-catchblock in thesubmitEvidencefunction improves error handling by capturing any errors fromconstructEvidence. This ensures thatisSendingstate is appropriately reset if an error occurs during evidence construction, preventing the application from remaining in a loading state.
105-114: PassinguploadFileas a Parameter toconstructEvidenceBy injecting
uploadFileas a parameter into theconstructEvidencefunction, the code promotes modularity and enhances testability. This approach decouples the function from external dependencies, making it easier to maintain and test.
jaybuidl
force-pushed
the
feat/atlas-ipfs-upload
branch
from
4c21930 to
96a49cc
Compare
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
- web/.env.devnet-neo.public (1 hunks)
- web/.env.devnet-university.public (1 hunks)
- web/.env.devnet.public (1 hunks)
- web/.env.local.public (1 hunks)
- web/.env.mainnet-neo.public (1 hunks)
- web/.env.testnet.public (1 hunks)
- web/src/context/AtlasProvider.tsx (8 hunks)
- web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx (3 hunks)
- web/src/pages/Resolver/Policy/index.tsx (2 hunks)
- web/src/utils/atlas/uploadToIpfs.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
- web/.env.devnet-neo.public
- web/.env.devnet-university.public
- web/.env.devnet.public
- web/.env.local.public
- web/.env.mainnet-neo.public
- web/.env.testnet.public
- web/src/pages/Cases/CaseDetails/Evidence/SubmitEvidenceModal.tsx
- web/src/pages/Resolver/Policy/index.tsx
🧰 Additional context used
📓 Learnings (1)
web/src/utils/atlas/uploadToIpfs.ts (1)
Learnt from: Harman-singh-waraich PR: kleros/kleros-v2#1687 File: web/src/utils/atlas/uploadToIpfs.ts:28-61 Timestamp: 2024-10-15T16:16:27.395Z Learning: In this codebase, the Toast wrappers handle the return value of `toast.promise`, ensuring that functions using it return the expected result.
🔇 Additional comments (10)
web/src/context/AtlasProvider.tsx (5)
17-24: LGTM: New imports and interface updates for IPFS functionality.The additions to the imports and the
IAtlasProviderinterface are consistent with the PR objectives. The newisUploadingFilestate anduploadFilemethod are appropriately typed and structured for the IPFS upload functionality.Also applies to: 35-41
74-74: LGTM: Updated GraphQL endpoint URL.The addition of
/graphqlto the endpoint URL is consistent with the PR objectives and ensures that GraphQL requests are sent to the correct endpoint.
140-140: LGTM: Simplified user existence check.The new implementation provides a more precise way to determine user existence by checking if the user's email is not undefined. This change aligns well with the comment about defining what constitutes an existing user.
282-283: LGTM: Context value updated with new IPFS-related properties.The addition of
isUploadingFileanduploadFileto the context value and the corresponding updates to theuseMemodependency array are consistent with the new IPFS upload functionality. These changes ensure that components consuming this context will have access to the new functionality and will re-render appropriately when these values change.Also applies to: 297-298
Line range hint
1-314: Overall assessment: Well-implemented IPFS upload functionality.The changes in this file successfully implement the IPFS upload functionality as described in the PR objectives. The code is clean, well-structured, and follows best practices. The new
uploadFilefunction and related changes are properly integrated into theAtlasProvidercomponent.There's only one minor suggestion to include
atlasUriin the dependency array of theuploadFilefunction'suseCallbackhook. Once this is addressed, the implementation will be fully robust and ready for merging.Great job on this implementation!
web/src/utils/atlas/uploadToIpfs.ts (5)
5-7: Product enum is properly definedThe
Productsenum is correctly set up, enhancing type safety by specifying allowed product types.
9-14: Roles enum includes all necessary rolesThe
Rolesenum comprehensively covers the possible roles needed for IPFS uploads.
16-21:IpfsUploadPayloadtype is well-structuredThe
IpfsUploadPayloadtype accurately defines all required properties for the upload payload.
23-26: Configuration type is appropriately definedThe
Configtype includes the necessary configuration parameters for the upload function.
28-61:uploadToIpfsfunction is correctly implementedThe
uploadToIpfsfunction properly handles the file upload process to IPFS, including error handling and user notifications. Given that the Toast wrappers in this codebase handle the return value oftoast.promise, the function is expected to return the correct upload result.
PR-Codex overview
This PR focuses on refactoring file upload functionality to IPFS by introducing a new
uploadToIpfsutility and integrating it into various components. It also removes obsolete files and updates environment variables.Detailed summary
uploadToIPFS.tsandauthMiddleware.ts.uploadToIpfsexport inweb/src/utils/atlas/index.ts./graphqlfromREACT_APP_ATLAS_URI.uploadFilefromuseAtlasProviderinPolicyandSubmitEvidenceModal.PolicyandSubmitEvidenceModalcomponents.uploadToIpfsutility with error handling and toast notifications.AtlasProviderto manage file upload state and logic.Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Documentation