refactor: isolate markAsCash from Onyx.connect data#73758
Conversation
…nnect/markAsCash-src-libs-actions-Transaction.ts
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
…nnect/markAsCash-src-libs-actions-Transaction.ts
|
@DylanDylann Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
LGTM |
|
@Skalakid Could you merge the new main? |
JmillsExpensify
left a comment
There was a problem hiding this comment.
Out of scope for product reviews, so I'm unsubscribing.
| function markAsCash(transactionID: string | undefined, transactionThreadReportID: string | undefined, transactionViolations: TransactionViolations = []) { | ||
| if (!transactionID || !transactionThreadReportID) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
This function uses Onyx.connect to retrieve the currentUserAccountID and currentUserPersonalDetails.
I think you could initially add optional props to it, with these data, and use the props.currentUserAccountID ?? fromOnyxConnect.currentUserAccountID inside buildOptimisticDismissedViolationReportAction.
I'd add a comment for the person who will be unbinding Onyx.connect in src/libs/ReportUtils.ts about why this implementation is there.
const optimisticReportAction = buildOptimisticDismissedViolationReportAction({
reason: 'manual',
violationName: CONST.VIOLATIONS.RTER,
});|
@Skalakid Kindly bump |
|
Hi, I'm Wiktor Gut from SWM agency and I'll be replacing @Skalakid in Onyx.connect issues, right now I'm also working on expo-video migration, but I'llcome back here ASAP |
|
Hi @dariusz-biela and @DylanDylann, it looks like I'm getting close to ending expo-video, so I came back to finishing Onyx.connect issues after Michał in the meantime. @dariusz-biela do I understand correctly, that the change proposed by you aims to make
|
…-fork into @Skalakid/refactor/useonyx-deprecate-onyx-connect/markAsCash-src-libs-actions-Transaction.ts
Overall, this is a new pattern that Michał and I planned to introduce. The assumptions for this pattern are as follows:
I’m not sure if this explains everything clearly, so if anything is still unclear, we can always jump on a call and talk it through. |
|
OK @dariusz-biela thank you for a quick reply; I went through some Onyx.connect issues (especially smaller ones, each one focused on a single function) and I didn't see any implementing similar design - each issue handled only specified function's parameters and usages + tests. I'm ambivalent on this topic because it could be a good idea, but it would also add quite a lot of comments that could be messy to clean. Moreover, the same way that we would offload next issues refactoring these helper functions, we would potentially bloat earlier PRs with optional props, comments and logic. @tgolen @DylanDylann it would be great to see if you're with this idea, otherwise I'd stick with leaving this PR like it's now. |
|
I am not quite following exactly what the question for me is, so you might need to be a little more direct in what you are asking. From looking at the PR, I think the code change here is fine and it's inline with all the refactorings that have been done to remove |
|
Hi @tgolen I'll try to rephrase it: What @dariusz-biela and @Skalakid were thinking about is adding optional props to all the functions that are used inside of the function we are working on here and that are using Onyx.connect themselves, so to Because these functions are yet to be migrated from Onyx.connect to useOnyx, when migrating them, devs will need to do just that - add props to all the functions using them and pass values extracted from useOnyx down from the components. The proposed solution would potentially speed up the process of migrating the mentioned functions, since some of the props and usages would already be done (all that would need to be done is removing 'optinality' from these props), though I think it would be less clear and ultimately lead to potential misunderstanding and more work. If you agree with me, than I think that this issue is ready for merge ✅ |
|
OK, I see what you're saying now. Thanks. I agree it could be a small time-saver, but I think it's riskier for the future refactorings because they might not catch that they need to update the params to be strictly required. In that case, it think it's better to just not have the optional params for now. I think the only way I would be OK with that is if YOU were for sure the one doing those future refactorings. |
Reviewer Checklist
Screenshots/VideosScreen.Recording.2025-12-16.at.11.04.53.movAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
|
We did not find an internal engineer to review this PR, trying to assign a random engineer to #67780 as well as to this PR... Please reach out for help on Slack if no one gets assigned! |
|
cc @tgolen |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/tgolen in version: 9.2.79-0 🚀
|
|
🚀 Deployed to staging by https://github.com/tgolen in version: 9.2.81-0 🚀
|
|
🚀 Deployed to production by https://github.com/AndrewGable in version: 9.2.81-5 🚀
|
|
🚀 Deployed to production by https://github.com/AndrewGable in version: 9.2.81-5 🚀
|
Explanation of Change
This PR is part of a refactor to remove Onyx.connect for the ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS key from the src/libs/actions/Transaction.ts file and replace it with useOnyx.
It isolates the
markAsCashfunction from the Onyx.connect data.To ensure this refactor doesn't break anything, it adds automated tests to the
markAsCashfunction.Fixed Issues
$ #67780
PROPOSAL:
Tests
Offline tests
Same as tests
QA Steps
Same as tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
web.mov