feat: quick freeze/unfreeze UTXOs on send page

[amitx13]

subtask of #689 This PR fixes #765
Quick freeze/unfreeze UTXOs from selected source Jar. Users will have the ability to select specific UTXOs when performing a direct-send or participating in a coin-join.

[theborakompanioni]

Getting tags[0] is undefined after sending a transaction (after the first tx from a clean npm run regtest:init):

Also, the modal opens immediately when selecting a source jar - is this intentional?

[amitx13]

Fixing one thing ended up causing a bit of a ruckus elsewhere. So it took a while to sort all of them 😂.

[amitx13]

@editwentyone Can you please take a while and assist me on what should be the deposit color? In our meet @theborakompanioni told that UTXOs with deposit tags should not have the mixed icon and green color,  So, what should it be instead? Should it be red or something else?

[editwentyone]

take grey like "regular" in the screenshot, its just a deposit, I don't think we need a highlight there

https://www.figma.com/design/kfejZJFlwBywvLEnPEmJo1/JoinMarket-UI?node-id=5267-69693&t=UyjfOQsttOYHnAmV-11

[amitx13]

Please take a look and let me know if there's anything I need to add or fix. 

[amitx13]

There is still an issue in the tooltip of the selected jar, tho. When the user clicks on the accordion (Sending Options), the scroll bar appears, and due to that, the tooltip gets displaced from its original position. I tried a few things, like forced rendering, but it did not work out as expected.

It can be fixed by increasing the size of the sendForm, but if anyone knows how it can be fixed, please let me know. It will be a great help.🙏

[theborakompanioni]

There is still an issue in the tooltip of the selected jar, tho. When the user clicks on the accordion (Sending Options), the scroll bar appears, and due to that, the tooltip gets displaced from its original position. I tried a few things, like forced rendering, but it did not work out as expected.

Think this is such a minor UI detail, it can be tackled in a follow-up PR!

Please take a look and let me know if there's anything I need to add or fix.

Generally, it works as expected.

Some thoughts regarding the code:

• nit: Try to follow the naming style and be consistent (e.g. mixing camelCase and snake_case) e.g. setshowingUTXOS -> setShowingUtxos in code (camelCase), or showUtxos.Select_UTXOs in translation files (snake_case )
• Try to use existing components instead of creating new ones
  • And if you must create new components, try make them reusable (e.g. let the caller provide onclick handler, etc.)
• Try to use the frameworks components instead of custom css

Small issues:

• If you deselect all UTXOs, you can cancel the alert and still confirm the action - freezing all UTXOs, which I assume, should be avoided?
• The modal buttons on mobile are displaced (resize browser window, see below)
• The UTXO list is not readable on small screens (resize browser window, see below)
• Labels with wrong color (see below), e.g. "reused" and "non-cj-change" background color is green, when it should be red/neutral
• Cannot click the Jar anymore to select (need to click the toggle button - which is small, hence difficult, on mobile)
• There is no loading indicator, when the freeze/unfreeze action is performed - users might have many UTXOs (one request per UTXO) or access the app via Tor (high latency) - which all slows down the process (try throttling your network speed to "Slow 3G" in your browser tools)

[amitx13]

Thanks for the feedback. @theborakompanioni really appreciates your efforts. Yeah, I tried using framework components, but in some cases it was not working as expected, so I wrote custom CSS. I will try to take a look one more time if I can somehow make it possible. 

I have a small doubt regarding the small issue (5th point): I cannot click the Jar anymore. The current flow is what Edi wanted (https://github.com/joinmarket-webui/jam/issues/765#issuecomment-2146943136),) so I implemented that. But if that's not what you want, could you please explain what the flow should be?

[theborakompanioni]

Thanks for the feedback. @theborakompanioni really appreciates your efforts. Yeah, I tried using framework components, but in some cases it was not working as expected, so I wrote custom CSS. I will try to take a look one more time if I can somehow make it possible.

I have a small doubt regarding the small issue (5th point): I cannot click the Jar anymore. The current flow is what Edi wanted (https://github.com/joinmarket-webui/jam/issues/765#issuecomment-2146943136),) so I implemented that. But if that's not what you want, could you please explain what the flow should be?

Thanks for the feedback. @theborakompanioni really appreciates your efforts. Yeah, I tried using framework components, but in some cases it was not working as expected, so I wrote custom CSS. I will try to take a look one more time if I can somehow make it possible.

If possible, take a look at other code parts that already use modals/dialogs/etc. At best, it would look the same or quite similar without additional custom styles.

I have a small doubt regarding the small issue (5th point): I cannot click the Jar anymore. The current flow is what Edi wanted (https://github.com/joinmarket-webui/jam/issues/765#issuecomment-2146943136),) so I implemented that. But if that's not what you want, could you please explain what the flow should be?

I guess you should still be able to select a jar by clicking the jar symbol which I think is in line with what @editwentyone suggested. Once it is selected, a second click opens the modal. Do you know what I mean?

[amitx13]

Okay, now I get it. Thank you for the explanation.

[editwentyone]

please add more padding top and bottom, that us way to close

[amitx13]

Reused 2 components ConfirmModal and SelectableJar Used react-table-library for the table as it is used in /wallet Fixed all of the small issue:

• confirm button disabled on warning
• No more displaced buttons
• Easy to read on small screen
• Corrected the Label colors (deposit - neutral , non-cj-change & reused - red , frozen - blue , joined & cj-out - green)
• Clickable Jar
• Loading indecator during Freeze/Unfreeze (I think it would be good if we can show some message like Please wait, your request is being processed. but for now, gone with the loading, as asked, what do you think?)

Please have a look 🙏 and let me know if there's anything I need to add or fix.

[editwentyone]

we discussed making the list after 5 entries scrollable for the time being.

after that maybe sorting by label and value, but that's out of scope

[barrytra]

I was trying to use this code for displaying UTXO list in FB creation modal as well. However the code breaks saying Cannot read properties of undefined (reading 'tag') Same issue persists for me if I run this branch and try to select UTXOs to send a transaction. @amitx13 is this fixed? If not lmk.. we can tackle this together. Or guide me if I am going wrong somewhere.

[amitx13]

I was trying to use this code for displaying UTXO list in FB creation modal as well. However the code breaks saying Cannot read properties of undefined (reading 'tag') Same issue persists for me if I run this branch and try to select UTXOs to send a transaction. @amitx13 is this fixed? If not lmk.. we can tackle this together. Or guide me if I am going wrong somewhere.

Hey @barrytra, Please hold off until tomorrow. I also need to reuse this component for https://github.com/joinmarket-webui/jam/issues/773, and I'm currently making some changes to it. I'll update you once I've resolved the issue.

[amitx13]

@barrytra Please have a look now. Additionally, I have also reused the component in this PR: https://github.com/joinmarket-webui/jam/pull/788/files look at src/components/Send/index.tsx

[barrytra]

I went through the code and tried using it as a component in FB creation. A suggestion from my side: How about if we export showUtxos component as a div and not a modal as a modal is not required in FB creation. U can append the modal over showUtxos component elsewhere. What do you think about it @amitx13 ?

[barrytra]

I was trying to use this code for displaying UTXO list in FB creation modal as well. However the code breaks saying Cannot read properties of undefined (reading 'tag') Same issue persists for me if I run this branch and try to select UTXOs to send a transaction.

moreover I am still getting this error on my setup :(

[amitx13]

I think you can still reuse the UtxoListDisplay and Divider components to make it work in FB creation becz you don't need the alerts and Confirmation modal that come with ShowUtxos and for your tag error, i think it's because you are not reloading the utxos like i have done in handleReload in ShowUtxos . I can help you with the code just push your changes and share your branch

[barrytra]

I think you can still reuse the UtxoListDisplay and Divider components to make it work in FB creation becz you don't need the alerts and Confirmation modal that come with ShowUtxos and for your tag error, i think it's because you are not reloading the utxos like i have done in handleReload in ShowUtxos . I can help you with the code just push your changes and share your branch

Okay!! I get that. I'll use UtxoListDisplay in FB creation. For the error part:While sending funds, It works fine if a Jar does not have any frozen Utxo but this error occurs when there is a frozen one. This is what I observed working with it. You can try creating a FB from a jar and freezing some Utxos, and then sending a txn through that jar

[amitx13]

I think you can still reuse the UtxoListDisplay and Divider components to make it work in FB creation becz you don't need the alerts and Confirmation modal that come with ShowUtxos and for your tag error, i think it's because you are not reloading the utxos like i have done in handleReload in ShowUtxos . I can help you with the code just push your changes and share your branch

Okay!! I get that. I'll use UtxoListDisplay in FB creation. For the error part:While sending funds, It works fine if a Jar does not have any frozen Utxo but this error occurs when there is a frozen one. This is what I observed working with it. You can try creating a FB from a jar and freezing some Utxos, and then sending a txn through that jar

Hey @barrytra I have re-tested the scenario you described, and it is working fine on my end. Before: After:

It seems like the issue might be due to an outdated build on your side.If you have a moment, could you please try pulling the latest changes from the PR and rebuilding the project? Thank you for your feedback and for taking the time to test the functionality I really appreciate your efforts

[barrytra]

It seems like the issue might be due to an outdated build on your side.If you have a moment, could you please try pulling the latest changes from the PR and rebuilding the project? Thank you for your feedback and for taking the time to test the functionality I really appreciate your efforts

I rebuilt it, but the issue still persists for me.. (IDK why). Let's wait until others review the same. Though thanks a lot for making the components. I'll try using them in FB creation.

[barrytra]

One more insight regarding the error: The code works perfectly fine for all jars except Jar A. Below are the UTXOs present in Jar A: What I infer is that last 3 UTXOs are empty and have no tag under them. This might be the reason I am getting the error: Cannot read properties of undefined (reading 'tag') At first place I don't really get why are those 3 empty UTXOs present there. But if this can be possible somehow then I think having this case (in which tag has no value) might solve the issue.

[amitx13]

Hmm, that makes sense. I'm not sure why those empty UTXOs are there, but it's definitely a good idea to handle this case. Thanks for catching that and solving the error, @barrytra . I really appreciate it. Great work, buddy!

[barrytra]

Great! Now it works perfect for me. Great Job @amitx13 . Let's wait for others to review it as well.

[theborakompanioni]

Quick feedback from looking over the changes. Code looks generally quite good. I think we are almost there! Well done :muscle:

• When a "sweep" is clicked and the amount is locked in, selecting (freezing/unfreezing) different UTXOs does not change the displayed (and subsequently sent) amount.

  

• Normal deposit UTXOs are rendered unreadable (in dark mode).

  

• All changes to PaymentConfirmModal.tsx are never active - can these changes be removed/reverted?

• In ShowUtxos, isLoading(true) is invoked in handleReload, while isLoading(false) is done in loadData. At best, this is done in the same function. e.g. set loading to true, make request, unset loading on success, abort or error. This should be done like this through-out the code base, so you can take a look at other code parts (if you find parts where it is not done this way, then that code is flaky as well).

  

• UTXOs with 9999 confirmations show 9999+ (instead of plain 9999)

Things that can be done in a follow-up PR:

• On selecting a Jar with only frozen funds the modal has an error message, which imho is unnecessary. Can the frozen UTXOs just be displayed?

• Nit: It would be nice for UTXOs with >9999 confirmations (that are displayed as 9999+) to show the real confirmations in a tooltip on hover (this can be done in a follow up PR)

Other considerations: Jam should discourage spending multiple "reused" UTXOs in different transactions, i.e. UTXOs sitting on the "same" address. They should be frozen/unfrozen together–or at least, show a warning to the user that what is being done is not advisable. This is not yet done in the Jar Details view so it does not necessarily have to be done in this PR. Just a heads-up.

[theborakompanioni]

Addendum: What is the default ordering of the UTXOs? Should it be descending by confirmations?

Maybe we should provide at least the possibility to order by value and confirmations (can also be done in a follow-up PR).. what do you think?

[editwentyone]

default could be by "date" in this case by numbers of confirmation, the older ones at the bottom, newer ones at the top.

being able to sort is awesome in a later PR

[amitx13]

• Fixed sweep amount

  1. prev - select jar -> checked sweep -> and now try to change the jar; you will see the amount in sweep is still reflecting the amount of the previous checked jar. which i think is wrong so i tried fixing that too.
  2. Selecting different UTXOs does change the displayed amount.

• Fixed Dark mode visibility

• For now All changes to PaymentConfirmModal.tsx are reverted. It will be later added to #788

• Fixed UTXOs confirmation bug and isLoading

• Prev On selecting a Jar with only frozen funds, the modal has an error message, which is now removed and few more new things are added

  1. Changed subheading when all the UTXOs are frozen
  2. Removed Divider line

[amitx13]

At last, Added the default sorting of UTXOs, with the older ones at the bottom, newer ones at the top. As discussed above,

[amitx13]

Please have a look @theborakompanioni and let me know if there are any modifications needed in the UI. Looking forward to your responses. And regarding the confirmation tooltip, it can be addressed in a follow-up PR.

[amitx13]

The tooltip was literally 10 lines of code so i ended up adding here. Behavior: The tooltip will only be visible on hover if the confirmation count exceeds 9999.

[theborakompanioni]

@amitx13 Nice work! Thanks for addressing this so quickly!

Found some more things, but those are minor and can be considered later on:

• reloading takes a long time (especially the /display request) on mainnet, which is not obvious during development (maybe we should introduce an optional artificial delay in dev:start?). So imho, it is not necessary to reload all data again, at least not /display - since it is loaded on initial page load and after a transaction has been made. What do you think?
• monospace font for displayed addresses
• removeClassName in Modal.tsx is confusing. I think it is either better to provide a different modal implementation or let users of the component provide the classes they want to use directly.
• wording for texts should be reviewed and potentially improved
• index in ShowUtxosProps is a String - can it be a JarIndex?

Since these points can be addressed in follow-up PRs and the current code works great: Approved! :rocket:

[amitx13]

Hey @theborakompanioni I appreciate your thoughts. Here is what i think

• reloading takes a long time (especially the /display request) on mainnet, which is not obvious during development (maybe we should introduce an optional artificial delay in dev:start?). So imho, it is not necessary to reload all data again, at least not /display - since it is loaded on initial page load and after a transaction has been made. What do you think?

Yes reloading takes a long time but /display request is essential for updating tags properly becz /display request is the one which appends the tag (status) for UTXOs After a transaction has been made,reloadUtxos is being called, not reloadAll. I think the only thing we can do to reduce time is to call reloadDisplay instead of reloadAll

[theborakompanioni]

Hey @theborakompanioni I appreciate your thoughts. Here is what i think

• reloading takes a long time (especially the /display request) on mainnet, which is not obvious during development (maybe we should introduce an optional artificial delay in dev:start?). So imho, it is not necessary to reload all data again, at least not /display - since it is loaded on initial page load and after a transaction has been made. What do you think?

Yes reloading takes a long time but /display request is essential for updating tags properly becz /display request is the one which appends the tag (status) for UTXOs After a transaction has been made,reloadUtxos is being called, not reloadAll. I think the only thing we can do to reduce time is to call reloadDisplay instead of reloadAll

Ah, yes, you are right.. only /utxo enpoint is reloaded after a transaction. Would it be possible and feasible to adapt that, i.e. reload /display after wallet UTXOs change but not loading it every time the modal is opened?

[amitx13]

I have optimized the UTXO display update logic. The /display request is now made only during the initial render and when opening the modal after a transaction, preventing unnecessary reloads each time the modal is opened.

Please take a look and, if everything looks good, merge the changes.

[theborakompanioni]

Some notes, that can be fixed in a follow up PR:

• change-out probably should get a color (yellow?) and not show the mixed icon

• Currently not really understand the function of isColorChange of Balance component - can you verify it does what you want? Only effect I see now is that it is not formatted and has some variant of the background highlight color. Maybe we can have both - color and format?

• The address should probably be monospace font.

• Remember resetting the amount field on sweeps when the source jar changes (follow-up PR!)

[amitx13]

• change-out probably should get a color (yellow?) and not show the mixed icon

Hey are there any resources that give an idea of all the tags available in Jam and their respective icons and colors? since it's not available in Figma Design.

• Remember resetting the amount field on sweeps when the source jar changes (follow-up PR!)

Hey, I've implemented the logic so that if Jar A is selected and sweep is true, the sweep amount of Jar A is shown in the amount input field, and now if Jar B is selected, the amount field updates to show the sweep amount for Jar B. However, if you prefer resetting it we can do that too.

[theborakompanioni]

• change-out probably should get a color (yellow?) and not show the mixed icon

Hey are there any resources that give an idea of all the tags available in Jam and their respective icons and colors? since it's not available in Figma Design.

Good point. I don't think there is.

• Remember resetting the amount field on sweeps when the source jar changes (follow-up PR!)

Hey, I've implemented the logic so that if Jar A is selected and sweep is true, the sweep amount of Jar A is shown in the amount input field, and now if Jar B is selected, the amount field updates to show the sweep amount for Jar B. However, if you prefer resetting it we can do that too.

Imho, resetting the value is preferable, as a user might be surprised otherwise and clicking the sweep button once is a reasonable trade-off. However, that can be done in a follow-up PR, as the changes are now consistent and additional adaptions can be discussed separately.

[amitx13]

If it is okay for you, I will merge this now and make some small adaptions in a follow-up PR.

Yea sure, feel free to merge the PR.

Thank you for your work and your time @amitx13. I think users will highly appreciate that feature, as it was quite circuitous before.

Thank you! I appreciate your kind words and the opportunity to contribute. Btw, just a heads-up on the bonus task (DirectSend RPC-Api): I reached out to some of my prev-mentors and mates, but none of them were able to identify why the OpenAPI Diff Action is throwing an error. However, I will keep looking into it and try to solve it. Let's see where it goes.