Open srinjoyc opened 3 years ago
Hey, Flow Surfer!
My name is Max. I am core member of Developer Experience team and I will be your Point-of-Contact for this task.
If you stumble into any challenges with this task, feel free to contact me via replies to this issue or over Flow Discord (my handle is MaxStarka#5714
).
Looking forward to work with you! :)
Hey Max, I want to make sure I'm understanding this correctly.
Since we are changing the return types of executeScript
and executeTransaction
in the flow-js-testing
library, won't that break any existing code that uses these functions? Not sure how to get around this.
For example, I'm imagining the intended refactor for executeScript is the following:
export const executeScript = async (...props) => {
try {
const extractor = extractParameters("script");
const { code, args } = await extractor(props);
const ix = [fcl.script(code)];
// add arguments if any
if (args) {
ix.push(fcl.args(resolveArguments(args, code)));
}
const response = await fcl.send(ix);
const result = await fcl.decode(response);
[result, null]
} catch (e) {
return [null, e]
}
}
Am I on the right track here?
@OmarMalik that is correct - this will be breaking change if your code previously wasn't using Jest helper methods.
There are 3 ways to go:
fcl.config
param to decide how returned value shall look and whether to catch error or notfcl.config
param in next release and deprecate it and old way of doing things in followingYour call ;)
Hey, @OmarMalik are you still working on this issue? :)
@OmarMalik if you are still working on this FLIP issue, can you let us know? If not, and if ok with @MaxStalker I'm hoping to do this one in the time that remains with @j00lz. Thanks
TeamExponential members: https://github.com/justjoolz https://github.com/hichana We would like to take on this flip if ok @MaxStalker.
Green light, @hichana !
Hello @MaxStalker, we have made our final submission for this FLIP fest issue: #91 Looking forward to your feedback and/or approval. Thank you
π Milestone Achieved! π
Thank you for your submission and participation!
Cheers @MaxStalker :)
Good day @hichana!
Thanks so much for all your hardwork & participation. In order to finalize winners & prepare for prize payout, we'll need the following actions from your end.
Please provide the following information byΒ Nov 17, 2021, (in this GH Issue is fine):
1. Team Information
πIMPORTANT: We will only proceed with prize payouts once all members have confirmed with π on the post.
2. Video Demo (optional)
We will be hosting Closing Ceremonies on November 23rd, 8AM PT where we'll having closing remarks from Dete & will be announcing the winners! I'll share the details here before Nov 17.
Hey folks,
We've received and reviewed over 82 submissions! What an amazing community on Flow! To commemorate all the hard work done, we have finalized winners and will be announcing them during our Closing Ceremony on Nov 23rd, 8AM PT. Be sure to join us - there may be some attendance prizes & a keynote from our CTO, Dete π!
RSVP here so you don't miss out! See you then!
Description (Problem Statement)
The JS Testing Framework has two functions:
sendTransaction
andexecuteScript
that currently return a single result from their execution. It does not have a good way of handling errors that should be caught and processed. This can cause issues with multiple interactions called in succession.Experience Required
Minimum Feature Set (Acceptance Criteria)
Catch error inside interaction code and always return tuple
[result, error]
.This should make it easier to assert the result of interaction using jest and other libraries.
Flow Cadut interactions are already implemented in such a way (refer to this piece of code as an example - https://github.com/onflow/flow-cadut/blob/main/src/interactions.js#L55-L63) so it's mostly a refactoring task.
Extension Feature Set (Optional)
Parse error message and provide an error in form of an object, containing at least
errorCode
,message
. If possible extract more information and format it in a human-readable and usable way.Milestone Requirements
Software Requirements
Maintainability
Code should be written with best practices in mind.
Other Requirements
Documentation
Code standards or guidelines
Judging Criteria
Resources