Bump up Yorkie to v0.5.4 #176
Conversation
WalkthroughThe pull request includes updates to various files, primarily focusing on version increments and type modifications. The environment variable Changes
Possibly related PRs
Suggested reviewers
Poem
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
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 (6)
tsconfig.json (1)
3-3: Consider documenting minimum browser requirements.Since ES2020 features are now being targeted, it would be helpful to document the minimum browser versions required for the application.
Add a section in your README.md or documentation about browser compatibility:
+ ## Browser Compatibility + + This application requires browsers with ES2020 support: + - Chrome >= 84 + - Firefox >= 79 + - Safari >= 14 + - Edge >= 84src/api/yorkie/v1/admin.proto (2)
164-165: Architectural enhancement with version vector support.Two significant changes here:
- Removal of
[jstype = JS_STRING]fromlamportfield aligns with the bigint handling improvements- Addition of
version_vectorfield enhances version tracking capabilities, which is a positive architectural improvementThe introduction of
VersionVectorsuggests a more sophisticated version tracking mechanism. Ensure that:
- Client code properly handles the new version vector field
- Documentation is updated to reflect this enhancement
- Migration guides are provided if this is a breaking change
Line range hint
1-196: Overall architectural improvements in v0.5.4.The changes in this proto file reflect two significant improvements:
- More robust type handling for int64 fields by removing string representations
- Enhanced version tracking through the introduction of version vectors
These changes align well with the upgrade to Yorkie v0.5.4 and should improve type safety and version management capabilities.
Consider:
- Updating API documentation to reflect these changes
- Providing migration guides if client code needs updates
- Adding examples of how to properly use the new version vector feature
src/api/yorkie/v1/resources.proto (2)
49-49: LGTM: Well-structured version vector implementation.The addition of VersionVector and its integration into ChangePack and ChangeID messages follows best practices for distributed systems. This enhancement will improve causality tracking and conflict resolution capabilities.
This change strengthens Yorkie's distributed consistency model by providing better version tracking at both the change pack and individual change levels.
Also applies to: 64-68
145-150: LGTM: Well-structured ArraySet operation.The new ArraySet operation follows the established pattern of other operations and includes all necessary timing fields. This addition enhances array manipulation capabilities.
Consider adding a comment above the ArraySet message to document its purpose and usage, similar to how the Select operation is documented.
+ // ArraySet operation allows direct value setting in arrays, providing an alternative + // to the existing Add/Remove operations for array manipulation. message ArraySet { TimeTicket parent_created_at = 1; TimeTicket created_at = 2; JSONElementSimple value = 3; TimeTicket executed_at = 4; }Also applies to: 163-163
src/api/yorkie/v1/admin_pb.ts (1)
19-19: Consider removing@ts-nocheckto enable type checkingThe directive
@ts-nocheckdisables TypeScript type checking for this file. Enabling type checking could help catch potential type errors in the generated code.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (17)
- .env (1 hunks)
- buf.gen.yaml (1 hunks)
- package.json (2 hunks)
- src/api/index.ts (3 hunks)
- src/api/types.ts (1 hunks)
- src/api/yorkie/v1/admin.proto (2 hunks)
- src/api/yorkie/v1/admin_connect.d.ts (0 hunks)
- src/api/yorkie/v1/admin_connect.ts (2 hunks)
- src/api/yorkie/v1/admin_pb.d.ts (0 hunks)
- src/api/yorkie/v1/admin_pb.js (0 hunks)
- src/api/yorkie/v1/admin_pb.ts (1 hunks)
- src/api/yorkie/v1/resources.proto (6 hunks)
- src/api/yorkie/v1/resources_pb.d.ts (0 hunks)
- src/api/yorkie/v1/resources_pb.js (0 hunks)
- src/api/yorkie/v1/resources_pb.ts (1 hunks)
- src/features/documents/documentsSlice.ts (2 hunks)
- tsconfig.json (1 hunks)
💤 Files with no reviewable changes (5)
- src/api/yorkie/v1/admin_connect.d.ts
- src/api/yorkie/v1/admin_pb.d.ts
- src/api/yorkie/v1/admin_pb.js
- src/api/yorkie/v1/resources_pb.d.ts
- src/api/yorkie/v1/resources_pb.js
✅ Files skipped from review due to trivial changes (1)
- .env
🔇 Additional comments (21)
buf.gen.yaml (2)
6-6: LGTM: TypeScript-native code generation is a good choice.Switching from
js+dtstotstarget is a positive change that:
- Generates TypeScript files directly instead of JavaScript + declaration files
- Reduces build complexity by eliminating intermediate JavaScript generation
- Better aligns with modern TypeScript development practices
Also applies to: 11-11
7-7: LGTM: Import extension configuration improves module compatibility.Adding
import_extension=noneis beneficial as it:
- Provides better compatibility with different module resolution strategies
- Aligns with modern ES module patterns
- Helps avoid potential import-related issues in different environments
Also applies to: 12-12
tsconfig.json (1)
3-3: Verify browser compatibility requirements.The upgrade from ES5 to ES2020 aligns well with the Yorkie v0.5.4 upgrade, especially for BigInt support. However, this change could affect browser compatibility.
Run this script to check if there's any documented browser compatibility requirements:
✅ Verification successful
ES2020 target is appropriate for the codebase's browser requirements
The change from ES5 to ES2020 is well-aligned with both the codebase and browser compatibility requirements:
- The browserslist configuration shows modern browser support:
- Production:
>0.2%,not dead,not op_mini all- Development: Latest Chrome and Firefox versions
- Multiple files already use ES2020 features (optional chaining, etc.)
- The configuration aligns with Yorkie v0.5.4's requirements for BigInt support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for browser compatibility documentation echo "Checking README and package.json for browser requirements..." rg -i "browser|compatibility|support" README.md package.jsonLength of output: 226
Script:
#!/bin/bash # Check browserslist configuration echo "Checking browserslist configuration in package.json..." cat package.json | jq -r '.browserslist' # Check for any browser-related configurations in other common config files echo -e "\nChecking for browser configurations in other files..." fd -e js -e json -e yaml -e yml -H -E node_modules -x grep -l -i "browser" {} # Look for any ES2020 specific features in the codebase echo -e "\nChecking usage of ES2020 features..." rg "BigInt|?.|\?\?|import\(|Promise\.allSettled" -lLength of output: 854
Script:
#!/bin/bash # Fix the regex pattern to properly escape special characters and check for ES2020 features echo "Checking usage of ES2020 features..." rg "BigInt|\?\.|\?\?|import\(|Promise\.allSettled" -l # Check for any type changes related to BigInt echo -e "\nChecking for BigInt type usage..." ast-grep --pattern 'type $_: bigint'Length of output: 685
src/api/types.ts (1)
27-27: LGTM! Type change improves precision handling.The change from
stringtobigintforserverSeqis a good improvement as it:
- Prevents potential precision loss
- Provides proper type safety for sequence numbers
- Aligns with the SDK upgrade to v0.5.4
Let's verify the impact on consumers of this type:
✅ Verification successful
Let me analyze the results and generate a final response based on the findings.
Type change to
bigintis properly handled across the codebaseThe verification shows that:
- All
serverSequsages are already handlingbigintvalues correctly- The SDK's protobuf definitions use
int64which aligns with thebiginttype- Key usage in
api/index.tsshows proper bigint operations (e.g.,serverSeq - 1n)🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all usages of DocumentHistory type to ensure consumers handle bigint properly # Search for direct DocumentHistory type usage echo "=== Direct DocumentHistory usage ===" rg -l "DocumentHistory" --type ts # Search for serverSeq property access echo -e "\n=== serverSeq property access patterns ===" rg "serverSeq" --type ts -A 2 -B 2Length of output: 1953
package.json (2)
45-45: Verify compatibility with updated yorkie-js-sdk.The dependency update to ^0.5.4 allows for compatible minor version updates. While the PR indicates no breaking changes, it's important to ensure comprehensive testing, especially given the TypeScript changes mentioned in the summary.
Let's check for potential breaking changes:
#!/bin/bash # Description: Look for potential breaking changes in TypeScript usage # Expected: Identify any bigint type changes that might need attention # Search for bigint type usage that might need updates echo "Checking for bigint type usage:" rg "type.*string" --type ts -B2 -A2 # Look for yorkie-js-sdk imports to verify usage echo -e "\nChecking yorkie-js-sdk usage:" rg "from ['\"]yorkie-js-sdk['\"]" --type ts -B1 -A1
3-3: Version bump aligns with PR objective.The project version update to 0.5.4 matches the intended Yorkie upgrade.
Let's verify the version consistency across the project:
✅ Verification successful
Version update is consistent across the project
The version bump to 0.5.4 is properly reflected in:
- package.json (project version)
- package-lock.json (yorkie-js-sdk dependency)
- All imports and usages of yorkie-js-sdk are clean without version-specific code
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check version consistency across project files # Expected: All version references should be 0.5.4 # Check .env file for VITE_JS_SDK_VERSION echo "Checking .env file:" rg "VITE_JS_SDK_VERSION.*0\.5\." .env || echo "Version not found in .env" # Check for any other version references echo -e "\nChecking other version references:" rg "0\.5\.[0-9]" --type-not jsonLength of output: 1797
Script:
#!/bin/bash # Let's check for version references in environment files and configuration echo "Checking environment files:" fd -t f "\.env" -x cat {} echo -e "\nChecking for version in vite config:" fd -t f "vite\.config" -x cat {} echo -e "\nChecking package-lock.json for yorkie version:" rg "yorkie-js-sdk" package-lock.json -C 2Length of output: 1430
src/api/yorkie/v1/admin.proto (2)
182-182: Consistent type handling change.The removal of
[jstype = JS_STRING]fromprevious_seqmaintains consistency with other int64 field changes.This change aligns with the overall improvement in type handling across the codebase.
159-159: Verify the impact of removing jstype option.The removal of
[jstype = JS_STRING]from theserver_seqfield indicates a shift in how int64 values are handled. This change likely improves type safety by using native bigint instead of string representations.✅ Verification successful
Removal of jstype option is consistent with codebase changes
The verification shows that:
- No remaining
jstype = JS_STRINGoptions exist in any proto files- All
int64fields includingserver_seqare consistently defined without jstype options- Generated TypeScript code (
*_pb.tsfiles) properly handles these fields asScalarType.INT64This change is part of a consistent update across the codebase to handle int64 values uniformly without string type conversion.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any remaining jstype = JS_STRING options in proto files # and verify consistent handling of int64 fields rg --type proto "jstype = JS_STRING" ./src/api # Check for related type handling in TypeScript files rg -t ts "server_seq.*string" ./srcLength of output: 116
Script:
#!/bin/bash # Search for jstype options in .proto files without relying on file type rg "jstype = JS_STRING" $(fd -e proto) # Search for all int64 field definitions in .proto files rg "int64.*=.*;" $(fd -e proto) # Search for server_seq usage in all files rg "server_seq" --type-not protoLength of output: 719
Script:
#!/bin/bash # Search for server_seq usage in all files without type filter rg "server_seq" --type all # Search for any remaining jstype options in all files rg "jstype.*=.*JS_STRING" # Look for TypeScript type definitions or interfaces related to these protos rg -l "interface.*SnapshotMeta|type.*SnapshotMeta"Length of output: 893
src/api/yorkie/v1/admin_connect.ts (3)
16-16: LGTM: Auto-generated file headerThis is an auto-generated file using protoc-gen-connect-es v1.4.0, which is consistent with the Yorkie version bump.
177-177: Type safety improvement with const assertionThe addition of
as constassertion improves type safety by making the AdminService object and its properties read-only at compile time. This is a positive change that prevents accidental modifications to the service definition.
Line range hint
1-177: Verify the generated code matches Yorkie v0.5.4 specificationsSince this is an auto-generated file, we should verify that it matches the expected output for Yorkie v0.5.4.
✅ Verification successful
Let me gather more information about the generated code and its specifications.
Let me verify one more aspect to ensure the generated code matches the proto specification.
Generated code matches Yorkie v0.5.4 specifications
The verification confirms that:
- The generated code perfectly matches the proto file specification with all 16 service methods correctly implemented
- All request/response message types are properly imported
- The code is generated for Yorkie v0.5.4 as specified in package.json
- The service interface maintains the exact structure defined in the proto file
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the Yorkie version and related configurations # Check package.json for Yorkie version echo "Checking Yorkie version in package.json:" jq -r '.dependencies["yorkie-js-sdk"]' package.json # Check environment variables for SDK version echo "Checking SDK version in environment files:" rg "VITE_JS_SDK_VERSION" -A 1Length of output: 772
Script:
#!/bin/bash # Check the proto file that generated this code echo "Checking the original proto file:" cat src/api/yorkie/v1/admin.proto # Check the protoc-gen-connect-es version used echo -e "\nChecking protoc-gen-connect-es version in package.json:" jq -r '.devDependencies["@bufbuild/protoc-gen-connect-es"]' package.json # Check if there are any other generated files with similar patterns echo -e "\nChecking for other generated files:" rg "@generated by protoc-gen-connect-es" --files-with-matchesLength of output: 5196
Script:
#!/bin/bash # Compare the service methods in proto and generated code echo "Comparing service methods:" # Extract methods from proto file echo "Methods in proto file:" grep "rpc" src/api/yorkie/v1/admin.proto | awk -F'[()]' '{print $1}' | awk '{print $2}' # Extract methods from generated code echo -e "\nMethods in generated code:" grep "name:" src/api/yorkie/v1/admin_connect.ts | awk -F'"' '{print $2}' # Check the imports to ensure all message types are properly imported echo -e "\nChecking imports in generated code:" grep "import {.*} from" src/api/yorkie/v1/admin_connect.tsLength of output: 1709
src/api/index.ts (4)
17-17: LGTM: Import changes align with SDK upgrade.The addition of
VersionVectorimport is consistent with the Yorkie SDK v0.5.4 upgrade and its usage in the code.
157-161: LGTM: Improved sequence number handling with bigint.The change to use native bigint arithmetic (
serverSeq - 1n) is more efficient and type-safe compared to string manipulation.
165-165: Verify the empty VersionVector initialization.While the addition of
VersionVectoris required by the SDK upgrade, please verify if initializing it with an empty Map is the intended behavior for snapshot application.✅ Verification successful
Let me gather more context about the VersionVector usage, particularly around snapshot application.
Let me search specifically for the document snapshot application logic to understand the context better.
Based on the gathered context, I can now provide the final response:
Empty VersionVector initialization is correct for snapshot application
The empty VersionVector initialization is the intended behavior here since:
- The snapshot is being applied at a specific sequence point obtained from the server
- The version vector is initialized fresh as this is a snapshot application, not an incremental change
- The actual version information comes from the
snapshotMeta.snapshotparameter🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other VersionVector usage patterns in the codebase ast-grep --pattern 'new VersionVector($$$)'Length of output: 452
Script:
#!/bin/bash # Search for applySnapshot implementations and usages ast-grep --pattern 'applySnapshot($$$)' # Look for VersionVector related code rg "VersionVector" -A 3Length of output: 6031
Script:
#!/bin/bash # Search for document snapshot related code rg "applySnapshot" -B 3 -A 3 # Search for snapshot meta related code rg "snapshotMeta" -B 3 -A 3Length of output: 1083
143-146: Verify the impact of type change from string to bigint.The parameter type change from
stringtobigintis appropriate for sequence numbers, but we should verify that all callers have been updated accordingly.✅ Verification successful
Let me gather more information to ensure we have a complete view of the type change impact.
Let me try one final verification approach to find the usage patterns.
Type change from string to bigint has been properly implemented
The verification shows the type change is consistently handled:
- The API function in
src/api/index.tsdeclarespreviousSeqasbigint- The Redux thunk in
src/features/documents/documentsSlice.tscorrectly:
- Declares
previousSeq?: bigintin its parameters- Uses a bigint literal
0nas default value- Passes the bigint value to the API function
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for calls to listDocumentHistories to ensure they use bigint rg -l "listDocumentHistories.*previousSeq.*string" || echo "No string type usage found" # Search for any remaining string to bigint conversions that might need updating ast-grep --pattern 'previousSeq: string'Length of output: 158
Script:
#!/bin/bash # Search for all usages of listDocumentHistories to see how previousSeq is passed rg "listDocumentHistories.*previousSeq" -A 2 # Search for any bigint type declarations related to previousSeq ast-grep --pattern 'previousSeq: bigint' # Look for any string to bigint conversions that might be related rg "BigInt\(.*previousSeq.*\)"Length of output: 122
Script:
#!/bin/bash # Search for function declarations and calls with broader context rg -A 5 -B 5 "listDocumentHistories" # Find any files that might contain the interface or type definitions fd -e ts -e tsx -x grep -l "DocumentHistory" # Look for any sequence-related type conversions more broadly rg "BigInt\(" -A 2Length of output: 4549
src/features/documents/documentsSlice.ts (3)
127-127: LGTM: Type change from string to bigint improves type safetyThe change from
stringtobigintforpreviousSeqis a good improvement as it provides better type safety and precision for sequence numbers.
133-133: LGTM: Appropriate use of bigint literal for default valueThe default value
0ncorrectly uses the bigint literal syntax and maintains type consistency with the parameter type.
Line range hint
127-145: Verify consistent bigint usage across callersLet's verify that all callers of
listDocumentHistoriesAsynchave been updated to handle the newbiginttype forpreviousSeq.✅ Verification successful
Based on the results from our verification scripts, I can now provide a final response:
biginttype change appears to be properly containedThe changes to
previousSeqtype are well-encapsulated within thedocumentsSlice.tsandapi/index.tsfiles, where:
- The type is properly defined as
bigintin the interface- Default value is correctly set as
0n(bigint literal)- The value is properly converted to string when needed via
String(previousSeq)- The API layer correctly handles the
biginttypeNo direct usage of
listDocumentHistoriesAsyncwas found in UI components, suggesting the pagination logic is likely handled through Redux state management, which properly processes the values without exposing the implementation details.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for calls to listDocumentHistoriesAsync rg "listDocumentHistoriesAsync\(" -A 3 # Search for any remaining string-typed previousSeq references ast-grep --pattern 'previousSeq: string'Length of output: 83
Script:
#!/bin/bash # Search for calls to listDocumentHistoriesAsync with more context and case-insensitive rg -i "listDocumentHistoriesAsync" -B 2 -A 5 # Search for type definitions or interfaces containing previousSeq ast-grep --pattern 'interface $_ { $$$ previousSeq: $_ $$$ }' # Search for any direct usage of previousSeq rg "previousSeq" -B 2 -A 2Length of output: 4041
Script:
#!/bin/bash # Search for components or hooks that might be using the document history functionality rg -l "useAppSelector.*history" -g "*.tsx" -g "*.ts" # Search for dispatch calls with listDocumentHistoriesAsync rg "dispatch\(.*listDocumentHistoriesAsync" -B 2 -A 2 # Look for any UI components handling previousSeq rg "previousSeq" -g "*.tsx" -B 2 -A 2Length of output: 148
src/api/yorkie/v1/resources.proto (1)
61-62: Verify JavaScript client compatibility.The removal of
jstype = JS_STRINGoption for int64 fields could affect JavaScript clients. This change means these fields will now be handled as bigints in JavaScript instead of strings.Let's verify the impact:
Also applies to: 341-341, 352-352
✅ Verification successful
Let me check the content of these files to understand how these fields are being used.
Based on the search results, I can now generate the final response:
The int64 fields are already using proper bigint handling
The generated TypeScript code shows that
server_seqandlamportfields are properly handled usingprotoInt64.zeroinitialization andScalarType.INT64type definitions. The removal ofjstype = JS_STRINGaligns with the current implementation as:
- All int64 fields are initialized with
protoInt64.zero- The field definitions use proper
ScalarType.INT64type- No string-based conversions are being used in the codebase
This indicates the JavaScript/TypeScript client is already prepared for bigint handling, making this change safe.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any JavaScript files that might be affected by the int64 type change # Look for files accessing these fields rg -l "server_seq|lamport" --type ts --type js # Look for any type definitions or conversions rg -l "(?i)(string.*int64|int64.*string)" --type tsLength of output: 200
Script:
#!/bin/bash # Check the content of affected files echo "=== resources_pb.ts ===" rg -A 5 -B 5 "server_seq|lamport" src/api/yorkie/v1/resources_pb.ts echo "=== admin_pb.ts ===" rg -A 5 -B 5 "server_seq|lamport" src/api/yorkie/v1/admin_pb.ts # Check for any type conversion patterns echo "=== Type conversions ===" rg "toString\(\)|parseInt|Number|BigInt" src/api/yorkie/v1/resources_pb.tsLength of output: 4719
src/api/yorkie/v1/admin_pb.ts (1)
21-1346: Approved: Generated code aligns with protobuf definitionsThe generated classes and methods accurately represent the protobuf messages and are correctly implemented according to the
@bufbuild/protobuflibrary conventions.src/api/yorkie/v1/resources_pb.ts (1)
233-235: Ensure proper handling of the newversionVectorfield inChangePackandChangeID.The addition of the
versionVectorfield toChangePackandChangeIDmay require updates in serialization, deserialization, and processing logic throughout the codebase. Please verify that all relevant methods and functions correctly handle this new field to ensure consistent version tracking and synchronization.Run the following script to identify code that may need to be updated:
Also applies to: 351-353
✅ Verification successful
Based on the search results, I can now provide a final response:
The
versionVectorfield is properly handled in the protobuf-generated codeThe code shows that both
ChangePackandChangeIDclasses are auto-generated from protobuf definitions with proper handling of theversionVectorfield:
- The field is correctly defined as an optional
VersionVectortype in both classes- Serialization/deserialization is handled automatically through the protobuf runtime
- The field is included in the field definitions for both classes, ensuring proper encoding/decoding
No manual updates are needed as the protobuf compiler has generated all the necessary code to handle the new field correctly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for instantiations of ChangePack and ChangeID without the versionVector field. # Test: Find all instances where ChangePack is instantiated without the versionVector field. Expect: No matches. ast-grep --pattern 'new ChangePack { documentKey: $_, checkpoint: $_, snapshot: $_, changes: $_, minSyncedTicket: $_, isRemoved: $_ }' # Test: Find all instances where ChangeID is instantiated without the versionVector field. Expect: No matches. ast-grep --pattern 'new ChangeID { clientSeq: $_, serverSeq: $_, lamport: $_, actorId: $_ }'Length of output: 251
Script:
#!/bin/bash # Let's try a different approach to find ChangePack and ChangeID usage patterns # Search for ChangePack instantiations and related code rg "ChangePack" -A 5 -B 5 # Search for ChangeID instantiations and related code rg "ChangeID" -A 5 -B 5 # Search for any files that might handle serialization/deserialization of these types rg -l "toJSON|fromJSON|serialize|deserialize"Length of output: 11162
Script:
#!/bin/bash # Let's check for any usage of ChangePack or ChangeID construction/handling in the codebase # Look for any code that creates or processes ChangePack or ChangeID rg -B 3 -A 3 "new (ChangePack|ChangeID)" # Look for any code that handles versionVector rg -B 3 -A 3 "versionVector" # Look for any test files that might verify ChangePack or ChangeID behavior fd -e test.ts -e spec.ts -x rg -l "ChangePack|ChangeID" {}Length of output: 3608
| @@ -142,7 +142,7 @@ export const listDocumentHistoriesAsync = createAppThunk( | |||
| return getPaginationData({ | |||
| data: histories, | |||
| isForward, | |||
| previousID: previousSeq, | |||
| previousID: String(previousSeq), | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider updating getPaginationData to handle bigint natively
While the String() conversion works correctly here, consider updating getPaginationData's interface to handle bigint directly in a future update. This would maintain type consistency throughout the pagination logic and avoid unnecessary type conversions.
export const getPaginationData = <T extends {}>(params: {
data: Array<T>;
isForward: boolean;
- previousID: string;
+ previousID: bigint;
pageSize: number;
reverse?: boolean;
}): {Committable suggestion was skipped due to low confidence.
What this PR does / why we need it?
Bump up Yorkie to v0.5.4
Any background context you want to provide?
What are the relevant tickets?
Fixes #
Checklist
Summary by CodeRabbit
Release Notes
New Features
VITE_JS_SDK_VERSIONto version0.5.4.VersionVectormessage for enhanced versioning in document management.Improvements
previousSeqparameter types fromstringtobigintin relevant functions.Bug Fixes
Chores