Feedback - WebAuthn App QA Results

[arboleya]

Background

Feedback by @SilentCicero.

As I was building the WebAuthn wallet, I had to use various parts of the typescript SDK. Overall, the typescript SDK has a lot of great work done, and worked well in the end for the MVP. For production, there was certainly some missing features (like pre-staging transactions to produce things like final tx_id and gas that were missing). Overall, the Typescript SDK brings a lot to the table, but needs to improve its documentation to show off what it can do in full and help alleviate developer onboarding issues.

I'd suggest working with DevRel to help increase missing areas of documentation, in addition to doing a pass by the team itself.

Issues

• Lack of mention of testnet URL  #1547
• How to connect to testnet #1548
• Creating a local testnet  #1549
• Lack of import and constructor examples  #1550
• More types in the generated docs than in the written docs  #1551
• Better error messages for predicate setData  #1552
• Should accept Uint8Array as Array / data or bytes type #1553
• Improve DX for Predicate class #1457
• Investigate tree-shakeability of our umbrella fuels package #1460
• No unit (decimals) handling documentation #1554
• No section around numbers #1555
• Unhelpful and unorganized error messages #1556
• API generation and referencing #1557
• Too much padding in the API docs #1558
• Add CDN Availability #1397

Raw Feedback

Num	Issue	Title	Description
1	#1547	Lack of mention of testnet URL	There is little mention of the current production testnet URL, or how to get the latest specific one for all the APIs etc. I'd ensure this is clearly stated across the documentation, as well as having a pre-defined detait constant in which people can use to get the latest beta-4/5 etc. URL.
2	#1548	How to connect to testnet	There isn't nearly enough documentation around connecting to testnet, similar to issue 1. I'd increase or make more visible early how to connect to testnet. See Ethers.js docs.
3	#1549	Creating a local testnet	We could certainly increase docs early about how to create/configure a local testnet. While its in the docs, its sparse and later on, when it could be far more apparent at the beginning.
4	#1550	Lack of import and constructor examples	Each type/object should show me exactly where the module is, how to import it and how to construct it. There was a big lack of this for each type in the type section, which left me having to go read code to figure it out.
5	#1551	More types in the generated docs than in the written docs	There were more types mentioned in the API docs than in the written ones, I'd recommend ensuring if we have a new SDK type it gets properly documented in written and generated form.
6	#1552	Better error messages for predicate setData	The current encoding error messages were weak on details and should be improved.
7	#1553	Should accept Uint8Array as Array / data or bytes type	It's a pain having to convert between all kinds of array / bytes types. We should consider a connonical way to encode/decode between data and accept common forms of data like Uint8Arrays.
8	#1457	No prepare TX	There is no prestaging of txs, i.e. if I use predicate.transfer, I can't see the tx_id unless I construct things manually, consider a prestage like predicate.prepare.transfer so that we can see the final tx before we send. I know this is already being considered.
9	#1460	Bad tree shaking	I experienced large bundle sized when building with fuels-ts, I'd consider having a CI check to ensure the way we have the sdk published can be properly tree shaken. This could be due to my bundler, but we should check to ensure it's not.
10	#1554	No unit handling documentation	Nowhere in the documentation does it mention anything to do with units or handling large / small units with different levels of precision. This is very basic, and should be mentioned / included as to a proper way to do so. You can see the format/parse unit facilities of Ethers.js to see what that looks like.
11	#1555	No section around numbers	We should include an entire section around how numbers are handling, particularly big and small numbers and what the proper way to handle them are.
12	#1556	Unhelpful and unorganized error messages	We should organize all error messages and properly document them, so there is a consistent, helpful and descriptive set of error messages across the sdk instead of ones I experienced like "too small" with no value or details flagged.
13	#1557	API generation and referencing	All referenced types in the written docs should link to a clear, generated API reference in the docs, otherwise it's very difficult to track down what object is being discussed where, and how to find it. This will likely need to be auto-generated but can and should be done.
14	#1558	Too much padding in the API docs	This one is largely for @Sarah Schwartz but there is too much padding in the generated API docs for the TS SDK, I'd consider revising and look at the appropriate amount that other docs references use, even the original ts-sdk docs were better here.
15	#1397	Lack of CDN / UMD bundling support	A lot of developers rely on CDN support for their bundles/builds and many non TS developers. So having clear support for CommonJS / UMD / ESM over something like with unpkg would be very welcome. See https://github.com/FuelLabs/authn-sign/tree/master#cdn-via-umd for how I did it here.

Docs Improvements

• Docs where helpful but needed a lot more clarity on connecting with testnet / setting up local networks
• Better documentation around importing / constructing all objects, namely SDK types (like Fuel ABI types)
• Better documentation around handling units
• Better documentation around handling numbers (large and small)
• Better referencing of written docs to the API generated reference docs

SDK Improvements

• Check tree shaking
• Better error messages in the SDK
• Add prepare step for transactions across all transaction APIs
• Lack of CDN/UMD/CommonJS build for each TS module and for the entire fuels TS module.