# TX Builder 0.1.0

Audit/Investigate:
- [x] Follow TX lifecycle, examine what is DH specific, what is intrisic
- [x] Should we turn the arg type factory into a configurable factory? How much work is this? (No. Not yet)
- [x] What utils can be refactored into their domain specific libraries (cache, abi, tx-builder, mayber ethers)
- [x] What goofy patterns are left over from when we had to keep .env at the library/app level?
- [x] ABI utils are pretty useful on their own. How should these be organized? Should devs really have to pull in all of tx-builder to use this? (Yes)
- [x] Is it possible to extract all ethers utils into library? (Yes)

## A Much Smaller Refactor

- [ ] Create ``cache-utils``
- [ ] Rename CACHE_CONFIG to DH_CACHE
- [ ] Remove centralized Store config var
- [x] Create generic cache store function
- [ ] create DAOhaus cache store
- [x] Create decorated functions so that anyone can add to the store
- [x] Create decorated functions so that anyone can access a store
- [x] Create``abi-utils``
- [ ] Decorate caching functions for the abi store using DH store
- [ ] Update all imports for each cache utils library
- [ ] Pull abi specific caching from ``cache utils``
- [ ] ContractLego types go here
- [ ] Rename to ABI legos
- [ ] Create analogue ABI types
- [ ] Processed contract utils could go here
- [ ] Remove ``moloch-v3-data`` from tx-builder
- [ ] Create poll result data type based onPollSuccess
- [ ] create ``findTransaction`` inside of ``tx-builder``
- [ ] create variable and return types for ``findTransaction``

## Improve Patterns
- [ ] Configurable Poll (currently its hardcoded) and test
- [ ] Configurable RPCs
- [ ] Do we use localAbis prop? If not remove it.
- [ ] In decodeProposalActions Multicall Meta pattern is dependant on static data we may not have. What are we using this for? May not be able to refactor decoding to a static library if this is the pattern we have to use.
- [ ] Discuss with Brian about wrapping Modal methods at the transaction level vs. at the formBuilder level.
- [ ] What should formBuilder control
- [ ] What should TxBuilder control

### Did not work out

- [x] Create ``ethers-utils``
- [x] utils/types/contracts => ethers-utils/types/abi
- [x] Update all imports for above changes
- [x] utils/utils/encoding => ethers-utils/utils/encoding
- [x] Update all imports for above changes
- [x] fromWei to formatting
- [x] Update all imports for above changes
- [x] gas.ts from utils to ethers-utils
- [x] Update all imports for above changes
- [x] votingPowerPercentage, memberTokenBalanceShare, memberUsdValueShare, sharesDelegatedToMember, lowerCaseLootToken, checkHasQuorum from ``general.ts`` to ``moloch-v3-utils``
- [x] Update all imports for above changes
- [ ] toBaseUnits and toWholeUnits from ``utils`` to ``ethers-utils``
- [ ] Update all imports for above changes
- [ ] ``createContract`` in tx-builder to here
- [ ] Move decoding.ts in ``tx-builder`` to here
- [x] First, I have to discover if type data is stored in the encoded bytes array
- [ ] If it is, write a method that tests if the bytes data can be decoded this way
- [ ] Then create a factory for handling bytes data (we should write one for multicall)
- [ ] Test
- [x] If not, see if it's possible to append an encoded indentifier and manually add the type data to the bytes
- [x] Test
- [ ] Create a way to find that identifier in the bytes data.
- [ ] Then create a method to test for that indentifier
- [ ] Create a method that splits the args from the arg types using the identifier
- [ ] Create a method that hydrates the types and uses them to decode the arguments
- [ ] Add this into library and delete the former method for decoding arguments.