fix: preserve order of providers as passed into useInitializeProviders

[No-Cash-7970]

Description

This is a fix for issue #104. With this fix, the order of the providers when passed into the useInitializeProviders hook will determine the order of providers in the providers array returned by the useWallet hook.

Checklist

• Code compiles correctly
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary

[No-Cash-7970]

This was an issue that bugged me, so I was determined to fix it. 😂

[drichar]

This was an issue that bugged me, so I was determined to fix it. 😂

Love this!! Thank you so much for taking the initiative to provide a solution. In the NFDomains wallet menu, I work around this by using a sort function and an array of PROVIDER_IDs in the order I want the providers to be in. After this change none of that will be necessary!

You've got the right idea here. The goal is to set the order of initializedProviders properties up front, instead of letting the order of promises resolving determine the order of the properties in the returned object.

But instead of doing this by introducing a side effect to the map function (which is only meant to produce an array of promises), I think a better approach would be to reduce the providers array when initializeProviders is defined:

if (typeof window === 'undefined') {
  debugLog('Window object is not available, skipping initialization')
  return {} as SupportedProviders
}

const initializedProviders = providers.reduce((acc, provider) => {
  const providerId = typeof provider === 'string'? provider : provider.id
  acc[providerId] = null  // Set to null to preserve order of providers
  return acc
}, {} as SupportedProviders)

This achieves the same result, while being more readable and a clearer separation of concerns. What do you think?

[drichar]

You can implement the proposed change here if you like, or I can add a commit if that's easier. Excited to get this merged and released.

[No-Cash-7970]

@drichar
Thanks for the suggestion! I agree your solution has a clearer separation of concerns, so I made the change.