[FH-2] Ask Me/AMA

[FTCHD]

Part of FrameHack2 (500 PTS)

ℹ️ Terminology

• Viewer: The person using the Frame on a client.

• User: The person who created the Frame on FrameTrain.

• Creator: The person who created the template from which the Frame was created. This is you, creating a template right now!

• View: A React component that is called by a handler (like a controller in MVC architecture), which then gets rendered using Satori and returned as image.

• BasicView: A specific, existent, pre-made React component imported from @/sdk/components that is used for common scenarios where you need just a title, a (optional) subtitle and a (optional) bottom message. It was made so creators don’t write the same basic component over and over again. It also comes with a matching component to use in your Inspector to let the User customize it named BasicViewInspector, click here for details.

• Handler: A function that receives the VALIDATED POST message from a Farcaster client, does the handling it needs, and returns either Frame data (metadata + a View or an image), or transaction data.

• Inspector: A required React component present in each template that appears as the “Configuration” panel on FrameTrain. It’s the right side of the editor, and is made up of one Configuration.Root and multiple Configuration.Section's (see below). You import the Configuration parent from @/sdk/inspector.

• Section: In order to not overwhelm the user with all the settings at once, we separate these in tabs that the user can navigate to one at a time. This is done internally, you only have to structure the content of your Inspector in multiple Section components.

• Page: A an optional React component present in a template’s folder, that is displayed on the /${FRAME_ID}/show route. You can include such a component in your template to display a Page with a detailed view of the votes in the case of a poll template, achieving the same functionality as WePonder for example.

• SDK: The FrameTrain SDK, located in the @/sdk folder. It provides components and utilities for gating, fonts and much more. Start reading about the SDK here.

• Config: The configuration data the User sets in the Inspector for the current Frame being edited, which is saved in the DB and fed into the template at runtime.

• Storage: Think of this like the state, but persisted in the DB. You receive the storage in your handler, and can return a new value for it, which updates the column in the DB.

Description

• A re-interpretation of the ask.fm concept in a Frame. Viewers ask questions and the User can pick one and answer.
• Includes gating options so not everyone can ask questions.
• The Page.tsx component shows a list of questions and answers (if the question is answered), the User has a button next to each question that allows them to answer it from the UI as well.
• Take a look at the existing Poll template for inspiration.
• Make sure your Inspector looks good on mobile too and inside the Composer Action window on Warpcast Web and Warpcast Mobile. Testing is done using the Warpcast Composer Action Playground.
• Only the best, most thorough, and complete implementation will be accepted.

Inspector

• Has Section s for “Cover”, “Submitted”, “Success”, “Payment”, “Gating”
• The User can enable payments with a toggle, an amount input and an address input. The token is always USDC on Base. Bonus: Using PayWithGlide, allow the Viewer to pay in any token, without specifying the token beforehand.
• If payment is enabled, the User can set an address to be paid to, pre-filled in the Inspector with the user’s first verified address through a useEffect that checks if the current address in the config is undefined.
• Gating is done in the same as the existing Cal/Poll/Gated templates, using the GatingInspector component and runGatingChecks function. For more details see the Gating section of the SDK.

Views

• Cover: displays either an image or BasicView (user picks in the Inspector), has a textInput to submit questions and buttons for “Questions” (start browsing the questions) and “Submit”, to submit a new question (and if “public” is enabled in the config we store the fid and username of the Viewer as well).
• Question: if the Viewer is the User, the View has a textInput to answer the question and an “Answer” button. If the question has been answered show a “View Answer” button, and if payment is enabled by the User, “View Answer” triggers a transaction that makes a transfer from the Viewer to the User’s address. If the interactor is the User skip any check and show the AnswerView.
• Answer (for the Viewer): shows the answer, either as callback after paying or directly if the interactor is the User (or if the Viewer already paid because we store each payment in the storage). Has a “Back” and a “Share” button with a warpcast: deep link to share this Frame with the right URL params so that the question appears in the cast (not the Cover), the message in the deep link depends if the interactor is the User or a Viewer (”I just answered…” vs “Got an answer from @user…”).
• Answered (for the User): displayed after the User answered a question, has a “Share” button with a warpcast: deep link to share this Frame with the right URL params so that the question appears in the cast (not the Cover).
• Submitted: image or BasicView (user picks in the Inspector), displayed after a question is submitted.