Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameterizing Future types #93

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Parameterizing Future types #93

wants to merge 10 commits into from

Conversation

liamgriffiths
Copy link
Contributor

@liamgriffiths liamgriffiths commented Jul 4, 2024

The main idea here is that we'd like to use a parameterized Future type instead of more specific instances with associated methods and instead implement additional helpers as functions that are also parameterized by the Future types they accept and return.

This change would incur some amount of breaking changes, but maintain equivalent functionality with the goal of simplifying code/understandability for future SDK user code.

⚠️ Breaking Changes

Future types will be represented as a single Future generic type

// eg.
FutureString -> Future<string>
FutureNumber -> Future<number>
FutureObject -> Future<Object>
FutureBoolean -> Future<boolean>
FutureAnyObject -> Future<Object>

String Futures no longer implement the .concat instance method

This method was already exported under sb and can continue to be used as expected.

// before
let before = futureString.concat("some", "more", "strings"); // -> FutureString

// after
import { sb } from "substrate";
let after = sb.concat(futureString, "some", "more", "strings"); // -> Future<string>

Object Futures no longer implement the .get instance method

This method will be exported under sb (similar to other future methods)

// before
let before = futureObject.get("someProperty"); // -> FutureAnyObject
let before2 = futureObject.get("someProperty.path[123]"); // -> FutureAnyObject

// after
import { sb } from "substrate";
let after = sb.get<someType>(futureObject, "someProperty"); // -> Future<someType>
let after2 = sb.get<someType>(futureObject, "someProperty.path[123]"); // -> Future<someType>
let after3 = sb.get(futureObject, "someProperty"); // -> Future<unknown>

sb.jq helper function accepts non-string type parameters and deprecates type-mapping argument

Code that uses these previous type mappings should be updated.

// before
let before = sb.jq<"number">(futureObject, ".property", "number"); // -> FutureNumber

// after
let after = sb.jq<string>(futureObject, ".property"); // -> Future<string>
let after = sb.jq(futureObject, ".property"); // -> Future<unknown>

@liamgriffiths liamgriffiths marked this pull request as ready for review July 11, 2024 17:41
Copy link
Contributor

@kousun12 kousun12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i love this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants