Small type usage updates (#1916)

docs/start/types.basics.md

@@ -27,7 +27,7 @@ For example:
 
 ```js
 const { metadata } = await api.rpc.state.getMetadata();
-const modules = metadata.asV3.modules;
+const modules = metadata.asLatest.modules;
 
 // This will not work, because `name` is an instance of `Text`, not a string
 // const system = modules.find(m => m.name === 'system');
@@ -79,6 +79,8 @@ const [count, accountId] = tuple;
 console.log(`${accountId} has ${count.toNumber()} values`);
 ```
 
+When making a call that expect a `Tuple` input, pass it as an array, so to pass the example above into a call, it would be `.call([123, '5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY'])`
+
 ## Extending types
 
 For customized chains, the need exists to register types so the API is aware of how to decode values for those types. The next section will provide a [walk-through for the definition of custom types](types.extend.md) allowing the definition or re-definition of any type the API is aware of.

docs/start/typescript.md

@@ -38,13 +38,6 @@ const [nonce, balance] = await api.query.system.account<[Index, AccountData]>(AD
 
 In both these case we can instruct the TypeScript compiler that the type we are expecting in `Index` and `Balance` respectively, not just pure `Codec`. This means that functions like `.toNumber()` is available on both these types - as opposed to just the [general type defaults](types.basics.md#everything-is-a-type) with `.toHex()` and friends.
 
-## Future work
-
-As of this writing, there are still some gray areas to type detection, specifically around the following interfaces -
-
-- `.at` & `.multi` on `api.query` does not (yet) have a `<TypeOverride>` interface. This means `as <TypeOverride>` casts are presently needed for these results
-- `api.queryMulti` does not (yet) allow you to provide a hint to the types returned, this ties to the previous point
-
 ## Adding user types
 
 In addition to the generated and available interfaces, there is also the ability to [create TypeScript interfaces from your own definitions and well as your on-chain modules](typescript.user.md).

docs/start/typescript.user.md

@@ -6,14 +6,14 @@ In the previous section we looked at the TypeScript definitions that are availab
 
 A large part of the type definitions are defined not as classes, but rather as structures from which type definitions are extracted and that can be used as-is to let the API know how to decode a type. By now you should be familiar with [type extensions](types.extend.md), but effectively the [types library does exactly the same](https://github.com/polkadot-js/api/tree/master/packages/types/src/interfaces).
 
-To create TypeScript-aware definitions and keep your files in a single place, you can follow the same approach. Assuming you have a package named `@MeInc/stuff` where you have the definitions in an `stuff/interfaces` folder. Each sub-folder would indicate a runtime module, e.g. 
+To create TypeScript-aware definitions and keep your files in a single place, you can follow the same approach. Assuming you have a package named `@MeInc/stuff` where you have the definitions in an `stuff/interfaces` folder. Each sub-folder would indicate a runtime module, e.g.
 
 - `stuff/interfaces/<module>/definitions.ts` for each module (`types.ts` & `index.ts` will be generated)
 - `stuff/interfaces/defnitions.ts` importing all sub-definitions`
 
 With this structure setup, you can generate TypeScript defintions.
 
-In the root of your project (with the `@polkadot/api`), you can run `yarn polkadot-types-from-defs --input ./stuff/interfaces --package @MeInc/stuff/interfaces` which will create `types.ts` and `index.ts` files with the generated types. You can use these in exactly the same way as you would use your types from `@polkadot/types/interfaces`.
+In the root of your project (with the `@polkadot/typegen` package installed), you can run `yarn polkadot-types-from-defs --input ./stuff/interfaces --package @MeInc/stuff/interfaces` which will create `types.ts` and `index.ts` files with the generated types. You can use these in exactly the same way as you would use your types from `@polkadot/types/interfaces`.
 
 ## Chain modules