kyra Comments - Answer Overflow

kyra

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

By the way, the docs are a bit oddly formatted but, you can check all the methods Result has here: https://sapphirejs.dev/docs/Documentation/api-utilities/@sapphire/result/classes/Result/#methods

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

And Sapphire args always throw an extension of UserError, so if you're not doing dynamic handling nor error message customization, you can do .pick instead

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

export function implementSkyraCommandError(identifier: string | UserError, context?: unknown): never {
    throw typeof identifier === 'string' ? new UserError({ identifier, context }) : identifier;
}

export function implementSkyraCommandError(identifier: string | UserError, context?: unknown): never {
    throw typeof identifier === 'string' ? new UserError({ identifier, context }) : identifier;
}

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

And that'll send a translated message to the user using the guild's locale, using this code:

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

For example Skyra does this a lot:

const user = args.finished ? message.author : await args.pick('userName');
if (!user.avatar) this.error(LanguageKeys.Commands.Tools.AvatarNone);

const user = args.finished ? message.author : await args.pick('userName');
if (!user.avatar) this.error(LanguageKeys.Commands.Tools.AvatarNone);

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

And needless to say, Sapphire comes with error handlers so UserError is sent to the user

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

.unwrap() will throw an error if there's no value tho

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

And then on the last lines you do

const mode = getMode.unwrap();
let text = getText.unwrap();

const mode = getMode.unwrap();
let text = getText.unwrap();

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

Same for getText

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

- if (getMode.isErr()) getMode = { value: 'decode' };
+ if (getMode.isErr()) getMode = ok('decode');

- if (getMode.isErr()) getMode = { value: 'decode' };
+ if (getMode.isErr()) getMode = ok('decode');

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

All in all you can keep your code still, with minor changes

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

I really need to make AsyncResult and AsyncOption 😅

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

const mode = (await args.pickResult('enum', { enum: modes }))
  .unwrapOr('decode');

const text = (await (await args.restResult('string', { maximum: 1984, minimum: 2 }))
  .mapErrIntoAsync(() => {
    if (message.type === MessageType.Reply) {
      const ref = await message.fetchReference();
      return ok(ref.embeds.length > 0 ? ref.embeds[0].description : ref.content);
    }

    return err(new UserError('no input given, aborting...'));
  }))
  .unwrapRaw();

// ...

const mode = (await args.pickResult('enum', { enum: modes }))
  .unwrapOr('decode');

const text = (await (await args.restResult('string', { maximum: 1984, minimum: 2 }))
  .mapErrIntoAsync(() => {
    if (message.type === MessageType.Reply) {
      const ref = await message.fetchReference();
      return ok(ref.embeds.length > 0 ? ref.embeds[0].description : ref.content);
    }

    return err(new UserError('no input given, aborting...'));
  }))
  .unwrapRaw();

// ...

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

That being said, you made me realise I should add async variations of all the methods, so the following code becomes valid:

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

But like we support both handling your errors with Result, or with try-catch, it's your app, your code is up to you

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

The try-catch is precisely why we have Result, it's bulky otherwise.

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

I also understand a lot of people don't have written Rust code. It is after all a very powerful but very complicated to learn and use language. Which is why I focused so much on the documentation, so you can see the methods it has and what you can do with them, also predict the behaviour it will have once you execute it (which to be fair is hard without Result). There are patterns you can follow, for example those codeblocks are similar:

const result = await promiseResultMethod();
const value = result.unwrapOr('test');

const result = await promiseResultMethod();
const value = result.unwrapOr('test');

const value = await promiseNativeMethod().catch(() => 'test');

const value = await promiseNativeMethod().catch(() => 'test');

let value;
try {
  value = resultMethod();
} catch {
  value = 'test';
}

let value;
try {
  value = resultMethod();
} catch {
  value = 'test';
}

Or even with Option:

const option = await promiseOptionMethod();
const value = option.unwrapOr('test');

const option = await promiseOptionMethod();
const value = option.unwrapOr('test');

const value = (await promiseOptionMethod()) ?? 'test';

const value = (await promiseOptionMethod()) ?? 'test';

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

I can understand the feeling, my main app, @Skyra, is ridden with legacy code that just repels me. When she was a multipurpose app back then, a single change, even technically non-breaking, was breaking Skyra. It felt like this comic all the time: https://xkcd.com/1172/

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

And the changes in @sapphire/result v2.7.0: https://github.com/sapphiredev/utilities/pull/808

54 replies

SIASapphire - Imagine a framework

•Created by <RefCell<Mutex<Win>> on 11/9/2024 in #sapphire-support

weird behavior with args.*Result after updating to sapphire v5.3.1

If you wanna check the source code: https://github.com/sapphiredev/utilities/blob/main/packages/result/src/lib/Result.ts

54 replies

Gaming

Programming