Ssemantic-release-botchore(release): 9.7.6 [skip ci]
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat: native multipart upload (#3566) ## 🎯 Goal This PR adds optional native multipart upload support for React Native and Expo packages, with native iOS/Android uploaders, a JS axios adapter, upload progress propagation and new attachment progress UI. Additionally, it also moves pending attachment uploads onto `client.uploadManager`, adds local attachment id tracking, improves video/document attachment handling, and updates SampleApp to exercise the new native upload path. The reason why we decided to add an opt-in native upload is related to the fact that `axios` does not always report upload progress correctly on React Native, especially Android. It will sometimes either not update the progress at all or report it badly, causing UI glitches. Additionally, native uploads are much, much faster as we take advantage of streaming directly without any intermediate ephemeral files in order to do that. Finally, `axios` can easily break if an override to the underlying RN's `fetch` implementation has been made, especially on `Android`. ## What Changed - Added a shared native multipart upload module for iOS and Android, including request parsing, file/text multipart parts, progress events, cancellation, timeouts, response handling, and bounded response body reads. - Added native package and Expo package bindings for `StreamMultipartUploader`, plus native handler registration through `stream-chat-react-native` and `stream-chat-expo` - Added core JS helpers and public types for native multipart upload requests, responses, progress events, abort handling, and uploader creation - Added `installNativeMultipartAdapter` / `wrapAxiosAdapterWithNativeMultipart` to route multipart `FormData` axios requests through the native uploader when available, while leaving non-multipart requests on the existing adapter - Added `Chat` support for enabling native multipart uploads via `useNativeMultipartUpload`; SampleApp enables this path - Reworked pending message attachment uploads to use `client.uploadManager.upload` by local attachment id instead of directly calling `channel.sendImage` / `channel.sendFile` - Added `localId` propagation from local attachments into message attachments so pending uploads can be correlated with `client.uploadManager` - Updated message sendability and upload indicator behavior to depend on `allowSendBeforeAttachmentsUpload` rather than offline support - Added upload progress UI for image, video, file, and audio attachments, including circular determinate progress, media overlays, file/audio byte progress labels, and a short completion hold to avoid UI flicker - Added new overrideable/default components for attachment upload progress: `AttachmentUploadIndicator`, `CircularProgressIndicator`, and `MediaUploadProgressOverlay` - Updated gallery/video thumbnail rendering so pending media attachments can show upload progress overlays - Updated document picking in both native and Expo packages to generate thumbnails for picked video files (this was missing from V9 initially) - Updated iOS video thumbnail URL handling to strip query and fragment data from local file URLs - Refined native iOS shimmer behavior to reduce animation restarts, handle foreground/background transitions, visibility, alpha, trait changes, and resolved color updates more reliably (this should improve shimmer performance for iOS significantly) - Updated `Android` shared native source syncing to resolve shared native sources from the canonical project path - Replaced SampleApp’s `react-native-fast-image` dependency with `@d11/react-native-fast-image` ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android --------- Co-authored-by: Zita Szupera <szuperaz@gmail.com> | 4 个月前 | |
fix: expo clipboard and extend with cb api (#3758) ## 🎯 Goal Resolves [this Zendesk ticket](https://getstream.zendesk.com/agent/tickets/82587). ## 🛠 Implementation details `expo-clipboard` has changed their API from the synchronous `setString` to the asynchronous `setStringAsync`. Our optional dependency for this exact purpose was never really updated and so copying messages did not work whenever using `stream-chat-expo`. In this PR we address that. Additionally, I noticed that a confirmation/failure snackbar was missing from the clipboard feature and so we add one as well. Since changing to an async API is technically breaking, we'll rely on the success/failure callbacks for now and update this in the next major. We anyway want to get rid of the dependencies to these super small libraries and keep them inhouse. Will be backported to V8 as well. ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android | 1 个月前 | |
fix: expose default native handlers (#3704) ## 🎯 Goal This PR addresses [this GH issue](https://github.com/GetStream/stream-chat-react-native/issues/3379). While exposing a prop might be slightly more convenient, our native handlers have a ton of arguments we don't want to expose every single one of them separately as it will cause an argument storm. Instead, we expose the default native handlers and allow integrators to use them as they see fit. For example, they could invoke them with different properties, make them conditionally depend on configuration and similar. It would also make it easier to conditionally override the handlers in certain scenarios. Runtime passing of different arguments should still be done on the callsites themselves, this approach is more of a global switch to something else if necessary. ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android | 2 个月前 | |
feat: native shimmer and image loading redesign (#3467) ## 🎯 Goal In this PR, we redesign the implementation of `ImageLoadingIndicator` to present as a gradient shimmer with an activity indicator. Since we tried a couple of approaches (one with `LinearGradient` from `RNSVG`), at the end we settled for a purely native implementation for performance reasons. Having that many animated views be potentially active on the screen tanks scrolling performance of the `MessageList` (i.e a lot of images loading, perhaps with poor network conditions if they aren't cached). The shimmer is Fabric only, lives in shared native sources, and is exposed through the native handler registration flow for consistent integration across the current SDK setup. Visuals and behaviour are aligned between Android and iOS, keeping a single moving shimmer gradient, and tuning width/shape/alpha for a smoother effect closer to the previous output. For packaging and local development flow, native source sync is now driven from `shared-native` as the source of truth so local dev and release packaging stay aligned, with build/script flow updated so copies refresh automatically when running the sample app. I'm not yet sure this is the correct approach, but since this is relatively new as we didn't have that many native implementations in the SDK in the past it'll have to do for now and we'll of course refine it as we go on. Just for reference, the native shimmer implementation improves: - Scrolling on Android by about 30-40 FPS (yes, really) - Scrolling on iOS by about 10 FPS (it was fine-ish before as well) compared to a `LinearGradient` and `Animated.View` approach for rendering a shimmer. TODO: - [x] Write docs for the native side - [x] Some additional cleanup - [x] Maybe tweak/polish the shimmer/gradient a little bit more - [x] Consolidate where we copy resources from (probably one folder for the shared stuff, and we always copy from there) so that future native implementations are trivial to add and all of the tooling works - [x] Have another run at the `build.gradle` copying edge cases, I think this can be done simpler ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android --------- Co-authored-by: Khushal Agarwal <khushal.agarwal987@gmail.com> | 5 个月前 | |
chore(release): 9.7.6 [skip ci] | 26 天前 | |
fix: podspecPath warning (#3574) ## 🎯 Goal This PR removes the deprecated iOS `podspecPath` entries from the RN CLI and Expo packages' `react-native.config.js` files. RN CLI 20 rejects `dependency.platforms.ios.podspecPath` and for RN `0.76+` the CLI discovers the package root `*.podspec` automatically during autolinking. Verified with `npx react-native config` in `examples/SampleApp`. ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android | 4 个月前 | |
feat: native shimmer and image loading redesign (#3467) ## 🎯 Goal In this PR, we redesign the implementation of `ImageLoadingIndicator` to present as a gradient shimmer with an activity indicator. Since we tried a couple of approaches (one with `LinearGradient` from `RNSVG`), at the end we settled for a purely native implementation for performance reasons. Having that many animated views be potentially active on the screen tanks scrolling performance of the `MessageList` (i.e a lot of images loading, perhaps with poor network conditions if they aren't cached). The shimmer is Fabric only, lives in shared native sources, and is exposed through the native handler registration flow for consistent integration across the current SDK setup. Visuals and behaviour are aligned between Android and iOS, keeping a single moving shimmer gradient, and tuning width/shape/alpha for a smoother effect closer to the previous output. For packaging and local development flow, native source sync is now driven from `shared-native` as the source of truth so local dev and release packaging stay aligned, with build/script flow updated so copies refresh automatically when running the sample app. I'm not yet sure this is the correct approach, but since this is relatively new as we didn't have that many native implementations in the SDK in the past it'll have to do for now and we'll of course refine it as we go on. Just for reference, the native shimmer implementation improves: - Scrolling on Android by about 30-40 FPS (yes, really) - Scrolling on iOS by about 10 FPS (it was fine-ish before as well) compared to a `LinearGradient` and `Animated.View` approach for rendering a shimmer. TODO: - [x] Write docs for the native side - [x] Some additional cleanup - [x] Maybe tweak/polish the shimmer/gradient a little bit more - [x] Consolidate where we copy resources from (probably one folder for the shared stuff, and we always copy from there) so that future native implementations are trivial to add and all of the tooling works - [x] Have another run at the `build.gradle` copying edge cases, I think this can be done simpler ## 🛠 Implementation details <!-- Provide a description of the implementation --> ## 🎨 UI Changes <!-- Add relevant screenshots --> <details> <summary>iOS</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> <details> <summary>Android</summary> <table> <thead> <tr> <td>Before</td> <td>After</td> </tr> </thead> <tbody> <tr> <td> <!--<img src="" /> --> </td> <td> <!--<img src="" /> --> </td> </tr> </tbody> </table> </details> ## 🧪 Testing <!-- Explain how this change can be tested (or why it can't be tested) --> ## ☑️ Checklist - [ ] I have signed the [Stream CLA](https://docs.google.com/forms/d/e/1FAIpQLScFKsKkAJI7mhCr7K9rEIOpqIDThrWxuvxnwUq2XkHyG154vQ/viewform) (required) - [ ] PR targets the `develop` branch - [ ] Documentation is updated - [ ] New code is tested in main example apps, including all possible scenarios - [ ] SampleApp iOS and Android - [ ] Expo iOS and Android --------- Co-authored-by: Khushal Agarwal <khushal.agarwal987@gmail.com> | 5 个月前 | |
chore: upgrade to TypeScript 6.0.3, ES2022 target, and shared ts-config presets (#3663) ## What & why Upgrades every workspace to **TypeScript 6.0.3** with **`target: ES2022`**, and removes tsconfig duplication via a new shared preset package. Enabling type-checking across the previously-unchecked packages also surfaced (and this PR fixes) a pre-existing bug in the core package's published type resolution plus a batch of latent type errors. ## Changes ### Shared config - New **private** `@stream-io/typescript-config` workspace (`configs/typescript-config/`): - `base.json` — cross-cutting policy (ES2022 target, strict, interop, …) - `library.json` — full React Native library config (extends `base`) - Core, the native/expo wrappers, and all 3 example apps extend these instead of duplicating compiler options. Example apps array-extend `["<framework base>", "@stream-io/typescript-config/base.json"]`. ### TypeScript 6.0.3 / ES2022 - TS `6.0.3` in all 7 manifests; `target: ES2022` everywhere. - `lib` kept at `ESNext` — the SDK uses the ES2023 `Array.prototype.toReversed()`. - TS 6.0 no longer auto-includes `@types/jest`, so it's referenced explicitly from a test-only `package/src/__tests__/jest-globals.d.ts` (excluded from the published build). ### Core publishing fix (consumer-facing) - `react-native-builder-bob` emitted declarations under `lib/typescript/src/` while `package.json#types` pointed at `lib/typescript/index.d.ts` — so TS consumers couldn't resolve the SDK's types via `types`. Added `rootDir: "./src"` so declarations emit flat to match `types`. This was also the root cause that blocked the wrappers/examples from resolving core's types. - Exported `PickImageOptions` from the core entrypoint (defined+exported in `native.ts` but never surfaced from `index`). ### Wrappers (`stream-chat-react-native`, `stream-chat-expo`) - Added a `typecheck` script + tsconfig (they had neither). The dynamic optional-`require` shims relax `noImplicitAny`/`strictNullChecks`/unused checks (kept `noImplicitReturns`). - Fixed real bugs: missing `return`s in `shareImage`, missing `resizeMode`/`rate` on the video shim, an inconsistent `startRecording` return shape. ### Example apps - Fixed ~60 pre-existing latent type errors unmasked by enabling typecheck: theme palette typing (the legacy flat `colors` palette, read via a local `AppTheme` cast — behavior-preserving), null-safety guards, and several SDK-API-drift fixes. ### CI - `check-pr.yml` now runs `yarn typecheck` across the whole workspace (core + 2 wrappers + 3 examples) instead of only the core package; the root `typecheck` aggregate includes the wrappers. ## Verification - `yarn build` ✅ - `yarn typecheck` (core + 2 wrappers + 3 examples) ✅ **0 errors** - `yarn lint` ✅ ## Notes for reviewers - **Commit type**: filed as `chore:` (release-neutral). The core changes (flat `types` path + `PickImageOptions` export) are genuinely consumer-facing — if you want them shipped, retype as `fix:` to cut a patch. - **Wrapper strictness**: `strictNullChecks`/`noImplicitAny` are relaxed **only** for the two wrapper packages (dynamic optional-dep shims), not for core. - **Example theming**: the apps' custom `colors` palette was already inert for SDK theming (the SDK reads semantics/primitives, not `theme.colors`); this PR preserves that behavior. Migrating the palette to the token model to restore custom branding would be a separate enhancement. - Did not run the full unit suite locally (the only core source change is the additive `PickImageOptions` export); CI runs `test:coverage`. --------- Co-authored-by: Ivan Sekovanikj <ivan.sekovanikj@getstream.io> | 1 个月前 |