Investigate if we can replace useCheckoutAddress hook with direct interactions with wc/store/checkout

[opr]

We have a hook: useCheckoutAddress which, following #6455 is mostly an abstraction to the selectors and actions on the wc/store/checkout @wordpress/data store with a couple of extra functions and propertoes.

We should investigate if it is worthwhile removing this hook. The abstraction adds extra complexity to our codebase, and if we can avoid it we should.

If we do this, we will also need to add actions and cases in the reducer to handle the following:

• setEmail
• setBillingPhone
• setShippingPhone

And new selectors:

• defaultAddressFields
• showShippingFields
• showBillingFields

[senadir]

We should explore the model of saveEntity, editEntity of Gutenberg in which one is a local edit and the other is persisted to the server, this should replace the need for pushChanges either that or explore using thunks for persisting info.

[github-actions]

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

[alexflorisca]

This hook combines data from the cart data store with WC settings data. I've seen this in a few places. What do you think about adding the wc/settings data to a (potentially read-only) store? It's global state, it's used throughout our blocks and components in various places and it would simplify data access throughout. The only downside I see is that there may be a delay while the store is initialised with the data, therefore delaying anything that needs immediate access to it. I think this would be minimal but I don't know the codebase well enough to say wether this would be a real problem or not? @senadir @opr thoughts?

[alexflorisca]

Decided not to do this for now (p1668615895631919-slack-C8X6Q7XQU) closing.