fix(bridge-ui): preserve custom processing fee selection across components

[CodeDragonVN]

Description

This pull request solves an issue where the processing fee selection is not preserved when navigating between components in the bridge. Specifically, when a user selected 'None' as the processing fee, it would revert to the recommended instead of showing '0 ETH | Customized' after returning to the Import step, unlike when a custom fee was selected and remain at the Import Step.
This happened because hasEnoughEth would be set the it's false declaration in ProcessingFee.svelte, since the ProcessingFee component created in TokenInput.svelte wasn't binding the hasEnoughEth prop, which would then trigger unselectNoneIfNotEnoughETH($processingFeeMethod, hasEnoughEth) and set the processingFeeMethod to recommended.

Changes

• Ensured the hasEnoughEth prop is correctly bound and passed through to the ProcessingFee component within TokenInput.svelte.

How to Reproduce the Issue

1. Navigate to the 'Review' step of the bridge.
2. Select 'None' for the processing fee.
3. Return to the 'Import' step.
4. Observe that previously, the fee selection would reset to the recommended, but with this fix, it should now correctly show zero.

Screenshots

Description	Screenshot
The issue where the processing fee reverted to the recommended.
The custom fee selection being preserved as expected.
The fixed state showing the '0 ETH | Customized' fee preserved correctly.
Console warning indicating the missing hasEnoughEth prop.

[KorbinianK]

@CodeDragonVN Thanks for your effort and kudos to this very well formatted PR ❤️

• The processing fee should reset when you go back to the first step, as it is a reset. But I can see why you may want it to stick.

• I can't reproduce the console warning on the deployed bridge, how did you cause this warning?

[CodeDragonVN]

@KorbinianK, thank you for the acknowledgment!

Regarding the processing fee behavior, I see your point about the reset at the first step. However, the current behavior is somewhat inconsistent, as a custom fee or recipient address does not reset, but only selecting the 'None' fee does.

The reset of the 'None' fee is arbitrarily caused by the initialization of TokenInput. By default, hasEnoughEth is assigned false in ProcessingFee.svelte, and when the ProcessingFee component is instantiated by TokenInput.svelte without passing this prop, it triggers the unintended reset due to the logic in unselectNoneIfNotEnoughETH($processingFeeMethod, hasEnoughEth).
The cause of the 'None' fee reset is not the intentional design of a step reset but rather an oversight in not binding hasEnoughEth, which differentiates its behavior from other custom settings like the custom fee and custom recipient by getting reset.

Here's a screenshot illustrating that the custom fee does not get reset:

If the intention is for these settings to reset when returning to the first step, I can implement the logic and make another PR. Just let me know if you'd like me to proceed with those changes.

As for the console warning, it indeed appears under the specific circumstance if I omit the default false assignment of hasEnoughEth in ProcessingFee.svelte so my earlier assumption was incorrect.

[KorbinianK]

@CodeDragonVN
Valid point, it's indeed missing the binding to reset correctly.
Feel free to fix the issue. It should reset fully when going back to the start.
You can keep this PR open I suppose and just add the changes, but up to you.

[CodeDragonVN]

@KorbinianK, I took a moment to review the implementation in the NFT bridge's ImportStep.svelte and noticed it uses a reset pattern upon mounting:

const reset = () => {
  foundNFTs = [];
  $selectedNFTs = [];
  $selectedImportMethod = ImportMethod.NONE;
};
...
onMount(() => {
  reset();
});

Inspired by it, I've implemented a similar reset logic for the Fungible Bridge:

const reset = () => {
  $recipientAddress = null;
  $processingFeeMethod = ProcessingFeeMethod.RECOMMENDED;
};

onMount(async () => {
  reset();
});

Regarding the previous changes made in this branch, considering that they still enhance the overall code structure and functionality, I believe it would be beneficial to keep them.

Please let me know your thoughts on keeping these improvements as part of the branch. I'm open to any further suggestions or modifications you believe might be necessary.

[gitpoap-bot]

Congrats, your important contribution to this open-source project has earned you a GitPOAP!

GitPOAP: 2024 Taiko Contributor:

Head to gitpoap.io & connect your GitHub account to mint!

Learn more about GitPOAPs here.