• Lose isGenesis key and instead require a genesis placeholder tokenId
• Expand Action to accept an array of token actions per comment
• Validate and implement these inputs (will change how we build EMPP OP_RETURNs)
• (potentially) also lose the isMint key, since a MintAction will make this unnecessary

@bot preview-e.cash

default to dust sats if unspecified, variable name improvements

tests pass locally so pushing up for review; CI issues here seem unrelated to the diff

preview is not expected to work until this lands, ack on the basic concept of iteratively building this in its own dir and then migrating the site

see contrib/team-city/build-configurations.yml and add a preview-e.cash-v2 modeled after the existing preview-e.cash

• Remove cashtab/failed-tests.txt
• using await screen.findByText with timeout instead of await waitFor()...

this exists in a few spots in Cashtab, and is correctly fixed on the latest input -- the one on the Receive screen

nice imo this is much better than what we have currently. testing nit.

@bot preview-e.cash

ok some specific recommendations

In D18066#411944, @emack wrote:

In mobile mode, this new header now takes up 30% of the UI. I know it moves off the screen when scrolling but it reappears with navigating to a new component. I think tooltips like Staking and Savings should be able to be closed or minimized by the user? Or perhaps have an onHover icon?
Also the Learn more link on mobile screens are somewhat harder to click (maybe I just have fat fingers) - perhaps make the whole row a link?

In D18069#411927, @emack wrote:

are these the warnings you're referring to when npm run build? If so I'm still seeing them

In D18061#411855, @emack wrote:

If you input a large enough number Cashtab crashes with a WSOD and spits out a range error on console. Not a big issue but rather unsightly. The other send amount inputs throughout the app gracefully spits out a Unable to parse sendAmount as a number UI error instead of sharting.

lint

support prefix and suffix for customized input field currency clarification

fix year in header for Receive

function doc

lint

cleaned up, mvp

My main objection here

at the moment this is not worth implementing in cashtab

regtest handles basic cases for SLP and ALP now. Next up is cleaning up debug logs, function names, adding unit tests for untested functions.

rebase, get regtest working with SLP and ALP. NB we still have lots of cleaning up and other tests to add.

Pushed at a better-but-still-not-great stopping point, where regtest works for SLP actions

Add SLP actions to (working) regtest, NB still lots to do to clean up tests, implement ALP

alt approach would be to have a function prepareWrappedString that takes a string and maxChars as params, and returns the string truncated to maxChars

need to comprehensively handle the token name / ticker break-all issue

without break-all (current diff)

airdrops not flexing well

review is simplified in this type of diff if before + after screenshots highlighting what has changed are included in the test plan

rebase and wait for CI to clear but looks good

this is a complicated fix to a niche issue that impacts behavior everywhere. I don't see a compelling case for the impact of this diff justifying its complexity.

clean up loop logic, remove debug log, comments

Add info logging

better while loop logic, more clarity in error msg, use variable instead of hardcode 5 in comment

Overall, the approach here is not ideal. It's not straightforward to handle this elegantly in ecash-agora (or mb it is and I just haven't sat down to work out the math) -- but even if we do handle it in ecash-agora, the performance delta is probably not user noticeable.

this is not a great stopping point but I have done so many rewrites and changes now that wanted to get some kind of anchor in for reference

coming up for air, taking a look at what has happened

• As @emack mentioned, this is 2 diffs. Please make one diff to add the close, and another to add the delay
• npm test does not actually test the behavior described in this diff. If it is impractical to add a unit or integration test, the test plan should include a description of how to repeat the issue before this change, and how to demonstrate that the issue is resolved after this change. Then npm test is demonstrating that existing behavior is preserved with this patch.
• patch version bump npm version patch (can be for just the 2nd of these 2 diffs, or can be a separate npm version patch for each diff), update changelog section of README describing the change