fix: recipient field revalidation due to uncontrolled transaction multiple update on NFT send flow

[themooneer]

✅ Checklist

• npx changeset was attached.
• Covered by automatic tests.
• Impact of the changes:
  • ...

📝 Description

When use try to send nft, the recipientfield revalidation process wen to uncontrolled behaviour while transaction object reference is updated too many times and by consequence invokes the onChangeTransaction(bridge.updateTransaction(transaction, { recipient: value })); inside the useEffect that should be used ONLY when the account change.

• This fix will support the revalidation done in https://ledgerhq.atlassian.net/browse/LIVE-14904 as well as the current ticket

Before

beforeMultipleupdate.mov

After

fix.transaction.based.reval.mov

❓ Context

• JIRA or GitHub link:
  https://ledgerhq.atlassian.net/browse/LIVE-15444

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.
• Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

4 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
ledger-live-github-bot	⬜️ Ignored (Inspect)	Visit Preview		Dec 16, 2024 1:58pm
native-ui-storybook	⬜️ Ignored (Inspect)	Visit Preview		Dec 16, 2024 1:58pm
react-ui-storybook	⬜️ Ignored (Inspect)	Visit Preview		Dec 16, 2024 1:58pm
web-tools	⬜️ Ignored (Inspect)	Visit Preview		Dec 16, 2024 1:58pm

[KVNLS]

Please do not lie to React hooks dependencies, can you find another solution, please? I'm wondering if we can introduce another issue with this fix.

[themooneer]

@KVNLS i agree with the principle , but exhaustive deps create side effect too. For example, in this case, when the parent component made any change, there are a lot of uncontrolled behaviour, bridge transaction reference change alot, event handler drilled but uncontrolled too (parent component don't manage it well) , also the link between the inputs and the button is not done the better way (not inside a form with a traditionnal validation schema in order to detect the dirty state of it) a lot of anti-pattern that leads to explicitly run an effect when the account id change.
, it's not a question of lying on React, with clean architecture we may not need to do that, so whether we refactor it in order to detect change on the receipient input with ease or we force the validation on account.id change.
My previous implementation caused the issue while it wasn't lying on react.

[KVNLS]

It does not work and the previous fix too. Please revert the previous fix introduced with
#8621

Screen.Recording.2024-12-16.at.17.38.10.mov