Skip to content

Commit

Permalink
docs(sdk): add comments on old deployContract impls detailing that th…
Browse files Browse the repository at this point in the history
…ey're unused. Update README
  • Loading branch information
TillaTheHun0 committed Oct 9, 2023
1 parent 2f6e37e commit 6f74d68
Show file tree
Hide file tree
Showing 3 changed files with 36 additions and 0 deletions.
30 changes: 30 additions & 0 deletions sdk/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ interacting with `ao` Smart Contracts.
- [`createDataItemSigner`](#createdataitemsigner)
- [Debug Logging](#debug-logging)
- [Testing](#testing)
- [Project Structure](#project-structure)

<!-- tocstop -->

Expand Down Expand Up @@ -150,3 +151,32 @@ interested in.
Run `npm test` to run the tests.
Run `npm run test:integration` to run the integration tests.
## Project Structure
The `ao` SDK project loosely implements the
[Ports and Adapters](https://medium.com/idealo-tech-blog/hexagonal-ports-adapters-architecture-e3617bcf00a0)
Architecture.
All business logic is in `lib` where each public api is implemented and tested.
`dal.js` contains the contracts for the driven adapters aka side-effects.
Implementations for those contracts are injected into, then parsed and invoked
by, the business logic. This is how we inject specific integrations for
providers ie. `Warp`, `Irys`, or even platforms specific implementations like
`node` and the `browser` while keeping them separated from the business logic --
the business logic simply consumes a black-box API -- easy to stub, and easy to
unit test.
Because the contract wrapping is done by the business logic itself, it also
ensures the stubs we use in our unit tests accurately implement the contract
API. Thus our unit tests are simoultaneously contract tests.
`client` contains implementations, of the contracts in `dal.js`, for various
platforms. The unit tests for the implementations in `client` also import
contracts from `dal.js` to help ensure that the implementation properly
satisfies the API.
Finally, the entrypoints (`index.js` for Node and `index.browser.js` for the
Browser) orchestrate everything, choosing the appropriate implementations from
`client` and injecting them into the business logic from `lib`.
3 changes: 3 additions & 0 deletions sdk/src/client/browser/wallet.js
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,9 @@ export function createDataItemSigner (arweaveWallet) {
*
* injecting side effects allows stubbing arweave and arweaveWallet
* for the purpose of testing
*
* Currently unused, as the impl instead uses Irys to deploy contracts,
* but keeping for posterity (it's tree-shaken out in distribution bundles anyway)
*/
export function deployContractWith ({ logger: _logger, arweave, arweaveWallet }) {
const logger = _logger.child('web-wallet:deployContract')
Expand Down
3 changes: 3 additions & 0 deletions sdk/src/client/warp-gateway.js
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,9 @@ import { z } from 'zod'
/**
* Inject dependencies, so they are configurable,
* and stubbable for testing
*
* Currently unused, as the impl instead uses Irys to deploy contracts,
* but keeping for posterity (it's tree-shaken out in distribution bundles anyway)
*/
export function deployContractWith ({ fetch, WARP_GATEWAY_URL, logger: _logger, getTime = () => new Date().getTime() }) {
const logger = _logger.child('warp-gateway:deployContract')
Expand Down

0 comments on commit 6f74d68

Please sign in to comment.