Wallet flow

[ekzyis]

Description

based on #2397 close #2308

This PR introduces a three-step flow to attach wallets: 1. attach send 2. attach receive 3. settings

The settings can only be accessed if the wallet has at least one send or receive configuration (else we wouldn't be saving anything).

/wallets/settings has been removed because the settings can now be accessed by going through the flow.

After a wallet has been configured, each protocol can still be enabled/disabled via the familiar checkbox in the protocol form. Individual protocols can no longer be detached however; a wallet can only be fully deleted via the 'delete' button in the settings (not quite happy with the position of it though).

The logic for the multi-step form has been encapsulated into @/components/multi-step-form.js. It's agnostic of wallets and handles:

• rendering the progress and children based on which step we're currently on
• keeping form state across steps
• navigation, including via browser

TODO

• ✅ skip if form empty, else show 'next' and test credentials
• ✅ allow browser navigation to go back, too
• ✅ move wallet tests into own mutation
• ✅ save wallets
• ✅ update wallets
• ✅ handle wallets without send or receive
• ✅ fix detach vs cancel
• ✅ populate fields like url from previous form
• ✅ q&a
• ✅ refactor multi-form code into own component
• ✅ make enable/disable send/recv vs delete more clear

Video

2025-08-09.17-07-10.mp4

Additional Context

1. As mentioned in the description, I'm not quite happy with the position of the 'delete' button but not sure where else to put it.

2. This bullet point from Wallet flow #2308 has been skipped because it's better suited for a follow-up PR:

• at the end, dedicated page for gun and horse so they know what it means when they see it next to the nym of other stackers

Checklist

Are your changes backward compatible? Please answer below:

yes

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:

8. Tested attaching, configuring and deleting wallets that use lightning addresses, NWC or LNbits

For frontend changes: Tested on mobile, light and dark mode? Please answer below:

n/a

Did you introduce any new environment variables? If so, call them out explicitly here:

no

[huumn]

As discussed I'm mostly suspicious of the UI. I'm going to list off things that feel off to me. If you'd like me to intervene and fix them myself, let me know.

The progress thing works well but looks sloppy. Things don't line up and aren't centered. You might consider using svgs of circled numbers.

I find the form back button confusing as it matches the page back button. imo it should be < back and the text of the next should be next >. These will also help distinguish the look of the form nav from cancel/skip.

The tabbing for wallets deviates from the tabbing used on all other pages.

---

I'll continue light QA and comment with any other issues. Once that passes, I'll skim the code.

[ekzyis]

The progress thing works well but looks sloppy. Things don't line up and aren't centered.

Oh, I lost something during my refactor here:

stacker.news/components/multi-step-form.js

Lines 61 to 69 in 736e18e

	steps.map((label, i) => {
	const last = i === steps.length - 1
	return (
	<Fragment key={i}>
	<ProgressNumber number={i + 1} label={label} active={stepIndex >= i} />
	{!last && <ProgressLine style={{ marginLeft: '-4px', marginRight: '-13px' }} active={stepIndex >= i + 1} />}
	</Fragment>
	)
	})

This was supposed to have a different margin adjustment for the second line. This and filling the numbers with the background color (so the line can't appear inside the circle) is how I made the lines touch the number.

You might consider using svgs of circled numbers.

Yes, will use svgs instead

I find the form back button confusing as it matches the page back button. imo it should be < back and the text of the next should be next >. These will also help distinguish the look of the form nav from cancel/skip.

Yes, good idea

The tabbing for wallets deviates from the tabbing used on all other pages.

Ah, I see that the font weight and color is off. Will make sure to reuse the CSS from nav.module.css

[ekzyis]

whoops, accidentally deleted the branch for a moment

The progress numbers now use SVGs and look like this:

[ekzyis]

Now using arrow-left-s-fill etc. for the form navigation instead of the existing arrows for page navigation:

Had to manually adjust the padding of the next button to make it look good.

Using the theme class for the hover style of the arrow to go back was removed as now the style should apply when we hover over the parent. How hover styles are applied to SVGs needs to be rethought. Fixed in d63f201.

[huumn]

Looks much better. Thank you! I'm going to give it a quick QA/line-by-line and merge if all goes well.

[huumn]

I centered things a little more, and gave a few places padding, but it is otherwise good to go. It looks nice and works better!

I'll merge when you're more available.