feat: build on modular core-web

[okjodom]

• Declares a Federation class that can be used standalone to connect and interact with the federation
• FedimintWallet now uses Federation instead of FederationService while still sharing the same WorkerClient instance

[changeset-bot]

🦋 Changeset detected

Latest commit: 0c0b088

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@fedimint/core-web	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alexlwn123]

Hey @okjodom, Thanks for the contribution!

Love the idea to further modularize things.

Few questions:

• What's the benefit of allowing Federation to be instantiated as a standalone? The services are relatively tiny compared to the wasm instantiation, so I'd expect users to always instantiate the whole FedimintWallet, even if they only need a subset of the features.

• What's the motivation for the Base class? By default, I much prefer composition over inheritance, so I'd like to avoid javascript's OOP features (abstract classes, interfaces, etc.) unless there's a really good reason

[okjodom]

Hey @alexlwn123

What's the benefit of allowing Federation to be instantiated as a standalone? The services are relatively tiny compared to the wasm instantiation, so I'd expect users to always instantiate the whole FedimintWallet, even if they only need a subset of the features.

I am testing a scenario where I only need FedimintService, and FedimintWallet is not a good abstraction.

In this scenario, I totally could consume FedimintService and write custom logic for instantiating WorkerClient. This gives me more control to manage the worker state, but I am worried of missing out on 'best practices' for when to instantiate the worker, and keep track of the service having an active connection to a federation.

[okjodom]

What's the motivation for the Base class?

This is an attempt at sharing what look like 'best practices' for when to instantiate the worker, and keep track of the service having an active connection to a federation. At a high level, the methods initialize, open, waitForOpen and cleanup state trackers make sense as what I'd need on a live instance of a service or wallet, that can be used with multiple federations, but only with one federation active at a time.

I much prefer composition over inheritance, so I'd like to avoid javascript's OOP features (abstract classes, interfaces, etc.) unless there's a really good reason

Aggreed on preference for composition over inheritance. If initialize, open, waitForOpen and cleanup methods are common enough, maybe we could make them part of WorkerClient, or somewhere else, composable into the services?

[maan2003]

@okjodom see #95 the new RpcClient should be usable without anything else