Playground Feature: Multiple contracts per account

[srinjoyc]

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Flow developers use the playground to learn, experiment, and share Cadence code. The current playground model only supports a single account to have a single contract. We want to expand this feature to hold multiple contracts per account. This will require changes to the UI as well as the backend.

Experience Required

• Strong proficiency with TypeScript and React (frontend)
• Good proficiency with GraphQL
• Good proficiency with Go (backend)
• Good understanding of Cadence
• Good UX/UI design ability

Minimum Feature Set (Acceptance Criteria)

• Playground UI shows contracts per account and actions to be able to:
• Add, delete, and switch between contracts.
• Backend is able to support the UI and persist these contracts and accounts

Extension (Optional) Feature Set

Implement a variable number of accounts. The current number of accounts is limited to five but can be expanded to support fewer or more accounts as needed by the user.

Software Requirements

• All existing features must remain unaffected with the introduction of this feature.
• Please follow the existing design patterns used in both the frontend and backend codebases.

Milestone Requirements

1. Create wireframe mockups for the new UI that demonstrate how the feature will be added. Include a rough description of the backend changes needed to support the proposed UI.
2. Implement designed interactions, following existing style
   1. Implement necessary changes on the back-end side
   2. Implement necessary changes on the front end to consume the updated account information.

Resources

• Playground frontend repository
• Playground API repository

[MaxStalker]

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! :)

[bartolomej]

Hey, we would like to work on this task!

Our team github handles:

• jakic12
• bartolomej

Our hackerearth team profile:
https://www.hackerearth.com/challenges/hackathon/flip-fest/dashboard/d28305a/team/

[MaxStalker]

That's great news, @bartolomej !
Looking forward to your submission :)

[soetop]

Hello @MaxStalker

I would like to participate for this task. As I am new to Flow and HackerEarth, I was experimenting over the past few days. I am now ready to participate.

My github handle: soetop
My hackerearth team profile: https://www.hackerearth.com/challenges/hackathon/flip-fest/dashboard/d8f66c8/team/

My progress so far ...

• I have attached the mock-up for multiple contracts editing with this comment. Please refer to the tabs above the Cadence editor.

• backend is working for multiple contracts editing and deploying
• loading of the default/local project with multiple contracts per account
• in-progress for frontend

Target date to submit draft version is Oct 28 (Thursday)
Then I will make changes/updates based on feedback and add test coverage.

[soetop]

I have a question regarding contract deployment. Current way of handling contract redeployment is to clear all project states before adding the contract. This is not optimal/applicable for deploying multiple contracts under the same account.

I am planning to change the logic a bit by removing the contract if a contract with same name already exist then adding the contract (instead of clearing all project states).

In addition, I also noticed experimental contract update feature. Should I do that instead of the above logic of removing and adding?

[MaxStalker]

Welcome to the FlipFest, @soetop ! :)
Looking forward to your contribution :)

I would recommend to clear project state anyway, cause it might cause weird bugs, when storage could have resource with non-existing type.

For experimental update - not recommended, since it won't call init method on the contract, which is desired behaviour sometimes.

[soetop]

thanks @MaxStalker

The progress is a bit slower than I was planning but I now have the first commit with things working. There are still loose ends that I will fix in my next commit that is planned for tomorrow.

For your easy review, I have recorded a 1 minute screen record: https://youtu.be/Od1YxuHA0iA

Commits:
flow-playground
flow-playground-api

[soetop]

My follow-up question would be regarding how deployed contracts are managed with changes in contract codes as contracts are deployed with contract function names.

The flow I am thinking is:

• a new contract script is created (which is then stored in the datastore)
• upon contract deployment, deployed contract function name is saved back in the datastore
• upon edit and redeploy, if the contract function name:
  • has changed, shall I delete the previously deployed contract?
  • has not changed, clear project state and deploy

[MaxStalker]

Great job, @soetop !
That video was indeed helpful, cause I had some issues with playground-api on my machine 😅

For the contract deployment - we can go the same way as we have right now. I.e. - always clear state on contract redeployment :)
We can incorporate some UX changes outside of Flip Fest :)

[soetop]

Thanks @MaxStalker for your helpful inputs. I am wrapping up to submit milestone #2 before the deadline.

I have 3 questions as I am fixing loose ends and refactoring/cleaning code.

1. is it ok to continue submitting fixes after the deadline passes? I have seen in the announcement that we can continue to do for 1 more week.
2. there are breaking changes as we transition from 1-1 mapping to 1-many mapping of account and contract. Should I remove irrelevant code as well?
3. do I need to provide code for test and migration? If so is it ok to do at the very last?

[kerrywei]

Thanks @MaxStalker for your helpful inputs. I am wrapping up to submit milestone #2 before the deadline.

I have 3 questions as I am fixing loose ends and refactoring/cleaning code.

1. is it ok to continue submitting fixes after the deadline passes? I have seen in the announcement that we can continue to do for 1 more week.
2. there are breaking changes as we transition from 1-1 mapping to 1-many mapping of account and contract. Should I remove irrelevant code as well?
3. do I need to provide code for test and migration? If so is it ok to do at the very last?

Hey @soetop ,

1. As long as a PR is submitted on/before Oct 30, you have up to end of the day of Nov 7 to continue work on it and receive feedback from us
2. could you clarify a bit what you mean by breaking changes? we should not break any existing functionalities. this issue should aim to add additional functionalities (i.e. allow multiple contract interaction under one account) rather than deprecating any existing features
3. Written tests are highly recommended! could you clarify what you mean by migration? (cc @MaxStalker )

[MaxStalker]

@soetop
2. Can you clarify which irrelevant code you are
3. Test coverage for new functionality would be cool, yeah :)

As for migration, we haven't included it in requirements, but we would appreciate if you include it in solution 🙇

[soetop]

thanks @MaxStalker and @kerrywei for clarifications.

2. two changes are introduced (detailed documentation)
   • routing (mainly frontend)
   • one-to-many mapping between an account and contracts

However, no existing features were deprecated.
The backend could be maintained so that it works with the current frontend and the new frontend.

3. yes, i will add test coverage (added initial test coverages)

Migration could help with porting over old playground projects to the newer version. I would need more time for that.

[kimcodeashian]

Good day @soetop, @bartolomej!

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

• Team Members Information - Github Username + Email Contact + Percentage of prize allocation (total should = 100%)
• All mentioned members MUST react to the post with a 👍 which will act as confirmation that the information is correct, or a 👎 to indicate that the information is not correct.
• We will be reaching out via e-mail

🎖IMPORTANT: We will only proceed with prize payouts once all members have confirmed with 👍 on the post.

2. Video Demo (optional)

• Please provide a 5-minute video demo to be featured & showcased in the FLIP Fest Closing Ceremonies
• Link format & Downloadable (eg. Google Drive, Vimeo)
• Content Format (Problem Statement, your work / how you solved it, final outcome)

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.

[bartolomej]

@kimcodeashian Awesome! Here is our info.

Team members info

• jakic12

  • email: drusany.jakob@gmail.com
  • percentage: 50%

• bartolomej

  • email: bartolomej.kozorog@gmail.com
  • percentage: 50%

[kimcodeashian]

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!

[soetop]

@kimcodeashian Here is my info.

Here is a demo video: https://youtu.be/PEB1A5GRAbA
Here is documentation: https://laser-teal-a79.notion.site/Notes-for-changes-Flipfest-21-b2c49263e87a4551b57826070fe566a6

• soetop
  • percentage: 100%