owoer
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
I would want to try contributing better examples if I get time or if my potato brain can formulate a clear visual of it or if it's needed
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
👍🏽
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
and my dumb adhd brain can't make sense of all
assert equal statements in examples54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
so I said to myself lemme just ask in support forum to make it easier to understand for me 💀🙏🏽
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
actually I was reading that before opening this thread but the methods without examples went over my head 💀
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
and me coming from old commando js framework where users are still used to typing commands without having to pass any arguments and it sequentially asks the user to interactively input each argument one after other, I have some ideas to also have that type of args handling but that is probably offtopic to the OP so I apologise
thank you for simplifying this for me with the amazing examples you have provided, it genuinely made the refactor so much less stressful, I would give you a hug if we were in IRL
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
I have been meaning to extend UserError to customize the error messages that is more understandable to average discord users because with default hard-coded error messages like "There are no more arguments." the feedback I got is alot of users struggle to understand what they need to do, but I keep on forgetting
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
interesting 👀
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
yeah I was also thinking about that, I can handle that flexibly with try-catch 🙌
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
:ablobmindblown: me rn
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
ohhh I didn't know this can be simplified further like this
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
👍🏽
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
that try-catch also gives more flexibility on how I want to handle inputs from both success/failure pov so I guess that is why it feels the best choice for me :stolen_emoji:
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
I think I'll start refactoring my code slowly now, write a helper function to handle args then slap it in all 99 cmds then update to latest sapphire and see how it goes , thank you for all this help :luv:
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
sorry to say this 💀 but to my ADHD brain, that try-catch example makes the most sense because it feels more readable , in my head it went like "OHH OMG I can use it like this too? brooo this makes things so much easier to refactor 😭"
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
thank you for the kind words, it means a lot :sneakhug:
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
so if I have to remain up-to-date with sapphire then I'll have to change this in so many places in 2+ years old code which feels huge pain and stressful :WhenDespairGetsAtYou:
or I stay pinned on sapphire 5.2.1 forever and not have to deal with this unprepared change which kinda feels like breaking
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
sorry for long wall
54 replies
SIASapphire - Imagine a framework
•Created by owoer on 11/9/2024 in #sapphire-support
weird behavior with args.*Result after updating to sapphire v5.3.1
the thing is I'm not from rust background so I still find using both
args.pick etc and args.pickResult bit difficult to use, there is lack of sections/examples for args.*Result in sapphirejs.dev guide area makes it difficult for someone not as proficient as me
but as far as I remember from my early days here back when we had sapphire support in #old-sapphire-support , I used to struggle between which to choose between args.pick/rest vs args.*Result and the former never worked out for me due to so many ways I handle arguments in code, partly because lack of examples for it in the guide and partly because of my inability to understand how it works, so I had settled with args.*Result method since then and have used it everywhere because that feels more readable and fits with how I want to handle all sorts of arguments and atleast args.*Result was shown as one of the recommended ways back then in old support channel as rough examples from what I remember.
now that I find out the said method I was using was non-documented private field and disallowed in 2.7.0, it kinda feels like semi breaking change and if this were mentioned in #Announcements it would have been greatly helpful to someone like me.
To explain what I'm trying to say here, let me take the example you showed above:
what if a user inputs an invalid/unexpected/trollish argument here or let's say doesn't provide argument here, does it raise any error? if yes then do I check via isErr first then inform user? like how I'm doing currently or use args.pick(...).catch(() => ...) route? but that feels unpleasant UX wise, setting default can, at times, feel unwise than to parse/validate argument and inform user if the input doesn't match the expectation. Just trying to help you explain why I use args.*Result since so long.54 replies