Consider simplifying the SDK by using a singleton for DID Resolver about dwn-sdk-js HOT 8 CLOSED

can look at this as well with guidance#

from dwn-sdk-js.

Haven't thought too deeply about this, but the reason behind filing this issue was seeing many instances of the DID resolver passing down from DWN construction to a lot of classes. But not passing it down also has the downside of hiding this dependency, making it not obvious that the DID resolver is a critical dependency... so I have not made up my mind to know if this is really a good direction. So I am going to take this off the "good first issue" list.

But it is not too difficult to implement, an approach to implement this would be:

1. Create a singleton instance in did-resolver.
2. Reference the singleton resolver wherever DID resolver is used.
3. Allow setting of the singleton instance for ease of testing.

from dwn-sdk-js.

i understand the first 2 i think but not the last one what does it mean?

from dwn-sdk-js.

I meant to say "allow updating/changing the singleton instance so tests can mock it.

from dwn-sdk-js.

ok also i cant see where the Didresolver first gets instantiated in the file because from what i can see other files just import the clas and do '''didResolver: DidResolver'''

from dwn-sdk-js.

It is first injected through the Dwn constructor, then passed down in a cascading fashion.

from dwn-sdk-js.

ok just to make sure you mean every occurrence of i just change to a getInstance method from the singleton

from dwn-sdk-js.

Super low pri now, can always reopen if this becomes an issue.

from dwn-sdk-js.