Skip to content
This repository has been archived by the owner on Sep 14, 2023. It is now read-only.

chore: remove fluent api and clean up examples #254

Merged
merged 4 commits into from
Oct 2, 2022
Merged

Conversation

harrysolovay
Copy link
Contributor

Fluent API is no longer necessary (see #226). Cleaned up examples as well.

@harrysolovay harrysolovay marked this pull request as ready for review October 2, 2022 06:02
@harrysolovay harrysolovay requested a review from tjjfvi October 2, 2022 06:02
Copy link
Contributor

@tjjfvi tjjfvi left a comment

Choose a reason for hiding this comment

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

Two notes:

  • Three examples were removed entirely; as we currently use these as informal manual testing, I think they should stay (or be removed in a separate PR)
  • I see you deleted U.throwIfError; why? IMO it is much cleaner with it than the expanded version

util/error.ts Outdated
@@ -4,10 +4,3 @@ export function ErrorCtor<Name extends string>(name: Name) {
override readonly name = name;
};
}

export function throwIfError<T>(value: T): Exclude<T, Error> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why was this removed? I think this is a regression.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's used in 3 tests... an instanceof check is slightly larger, but it's clear what's happening in place (without following the import). In the case of examples: we want it to be extremely clear to users what's going on. My thinking is that throwIfError comes with an unworthy trade off: the cognitive load of bringing throwIfError into scope (and figuring out what it does) isn't worth the size savings. That being said, I agree: avoids the local binding on which to perform the instanceof check... are we (am I) overthinking this? Should we revert?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's used in 3 tests... and pretty much every single example. While we don't use it much in capi (since we tend to return results), I think it's a very useful utility for users and makes the examples a bit cleaner.

In terms of cognitive overhead, once one knows what it does, that's not a problem. Whereas with the expanded version, one has to read it to make sure it's the boilerplate and not doing something weird.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point! I agree. Reverting now.

examples/events.ts Show resolved Hide resolved
examples/polkadot_signer.ts Show resolved Hide resolved
examples/watch_events.ts Show resolved Hide resolved
@harrysolovay harrysolovay requested a review from tjjfvi October 2, 2022 18:40
@harrysolovay
Copy link
Contributor Author

I hastily removed all fluent examples (whoops). I've added non-fluent equivalents of the deleted examples.

tjjfvi
tjjfvi previously approved these changes Oct 2, 2022
Copy link
Contributor

@tjjfvi tjjfvi left a comment

Choose a reason for hiding this comment

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

I followed up on the throwIfError, but looks good otherwise

tjjfvi
tjjfvi previously approved these changes Oct 2, 2022
@harrysolovay harrysolovay merged commit cb8610b into main Oct 2, 2022
@harrysolovay harrysolovay deleted the remove-fluent-api branch October 2, 2022 19:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants