chore: second part of defaulting to save address.

[oxaudo]

This is a second case I found that should fix https://artsyproduct.atlassian.net/browse/EMI-1939

It's a bit roundabout way to fix it but I believe it's a proper condition to call this useEffect regardless of this bug even. But looks like it works here because when the last address deleted on the page the length of addresses change and the previous case that I fixed (default to save address when address is present on the order but there is no addresses in context - default to save address).

It's all a bit confusing but seems to work. Also not sure how to test any of this stuff cause the setup is pretty complicated. But maybe can tested with integration run after.

[relativeci[bot]]

#144 Bundle Size — 9.51MiB (+0.01%).

15c5a76(current) vs 2682a9f main#143(baseline)

[!WARNING] Bundle contains 45 duplicate packages – View duplicate packages

Bundle metrics   5 changes 1 regression 1 improvement

	Current #144	Baseline #143
Initial JS	4.32MiB(~+0.01%)	4.32MiB
Initial CSS	0B	0B
Cache Invalidation	16.87%	0.93%
Chunks	143(+0.7%)	142
Assets	146(+0.69%)	145
Modules	5551	5551
Duplicate Modules	379(-0.26%)	380
Duplicate Code	4.78%	4.78%
Packages	292	292
Duplicate Packages	42	42

Bundle size by type   2 changes 1 regression 1 improvement

	Current #144	Baseline #143
JS	9.3MiB (~-0.01%)	9.3MiB
Other	215.22KiB (+0.6%)	213.94KiB

Bundle analysis report Branch oxaudo/saved_address Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[erikdstock]

I still need to confirm this works but I have a fix for EMI-1944 which I think might achieve the same result: https://github.com/artsy/force/compare/erik.emi1944-clear-address-on-delete

What do you think? This way the value would be set when the form resets.

[oxaudo]

@erikdstock - I think your suggestion is legit as well but probably can be done in parallel. Both of those changes are legit I think. The effect in SavedAddresses here depends on savedAddresses.length and context stuff and should be rerun if any of those change. I beieve we added those at some point with some bug fix but forgot to update run dependency.

[erikdstock]

@erikdstock - I think your suggestion is legit as well but probably can be done in parallel. Both of those changes are legit I think. The effect in SavedAddresses here depends on savedAddresses.length and context stuff and should be rerun if any of those change. I beieve we added those at some point with some bug fix but forgot to update run dependency.

My thinking is this:

• The change I made uses the result of getInitialValues() in FulfillmentDetails, outside of SavedAddresses. That function does return the default saveAddress: true
• If the length of savedAddresses becomes zero, responsibility for the address form is returned to the no-saved-address shipping form (shippingFormMode === 'new_address')
• This responsibility makes sense higher up in the component tree, in the FulfillmentDetails component & at the same point that we change the mode.

Since I just did that at the end of the day yesterday I'd like to test whether it works first, but maybe there is some bug as you mentioned that this change is still worth it. Maybe we could talk through it?

[oxaudo]

Happy to merge your change first and see what's still off if anything. Happy to chet as well but probably not now as my connection here is so crappy and electricity is on/off today.