2.2 Scaffolding and Setup
In this tutorial, we’ll be building a version of Rock, Paper, Scissors! where two players, Alice and Bob, can wager on the result of the game. We’ll start simple and slowly make the application more fully-featured.
You should follow along by copying each part of the program and seeing how things go. If you’re like us, you may find it beneficial to type each line out, rather than copying & pasting so you can start building your muscle memory and begin to get a sense for each part of a Reach program.
Let’s start by creating a file named index.rsh. It doesn’t matter where you put this file, but we recommend putting it in the current directory, which would be ~/reach/tut if you’re following along exactly. In all the subsequent code samples, we’ll label the files based on the chapter of the tutorial you’re reading. For example, start off by typing the following into index.rsh:
1 'reach 0.1';
2
3 export const main = Reach.App(() => {
4 const Alice = Participant('Alice', {
5 // Specify Alice's interact interface here
6 });
7 const Bob = Participant('Bob', {
8 // Specify Bob's interact interface here
9 });
10 deploy();
11 // write your program here
12
13 });
Did you notice that
export,const,exit, and so on are links? In Reach code samples, you can click on the names of keywords and standard library functions to be brought to their documentation.
Did you notice that tut-2/index.rsh was a link in the box above the code sample? You can always click on these links to see the entire file in our GitHub repository.
Did you notice the attractive clipboard icon on the top the right of that box? You can click on it and the content of the code box will be copied onto your clipboard.
Did your text editor recognize index.rsh as a Reach program and give you proper syntax hightlighting? If not, check if there’s a plugin available for your editor by visiting IDE/Text Editor Support or manually configure it to treat Reach (.rsh) files as JavaScript and things will be mostly correct.
This is just a shell of a program that doesn’t do much, but it has a few important components.
Line 1 indicates that this is a Reach program. You’ll always have this at the top of every program.
Line 3 defines the main export from the program. When you compile, this is what the compiler will look at.
Lines 4 through 9 specify the two participants to this application, Alice and Bob.
Line 10 marks the deployment of the the Reach program, which allows the program to start doing things.
Before we go too much further, let’s create a similar shell for our JavaScript frontend code. Open a new file named index.mjs and fill it with this:
1 import { loadStdlib } from '@reach-sh/stdlib';
2 import * as backend from './build/index.main.mjs';
3 const stdlib = loadStdlib(process.env);
4
5 (async () => {
6 const startingBalance = stdlib.parseCurrency(10);
7 const accAlice = await stdlib.newTestAccount(startingBalance);
8 const accBob = await stdlib.newTestAccount(startingBalance);
9
10 const ctcAlice = accAlice.deploy(backend);
11 const ctcBob = accBob.attach(backend, ctcAlice.getInfo());
12
13 await Promise.all([
14 backend.Alice(ctcAlice, {
15 // implement Alice's interact object here
16 }),
17 backend.Bob(ctcBob, {
18 // implement Bob's interact object here
19 }),
20 ]);
21 })(); // <-- Don't forget these!
Did you notice that
parseCurrency,newTestAccount,deploy, and so on are links? In JavaScript code samples, you can click on the names of standard library functions to be brought to their documentation.
This JavaScript code is similarly schematic and will be consistent across all of your test programs.
Line 1 imports the Reach standard library loader.
Line 2 imports your backend, which ./reach compile will produce.
Line 3 loads the standard library dynamically based on the REACH_CONNECTOR_MODE environment variable.
Line 5 defines an asynchronous function that will be the body of our frontend.
Line 6 defines a quantity of network tokens as the starting balance for each test account.
Lines 7 and 8 create test accounts with initial endowments for Alice and Bob. This will only work on the Reach-provided developer testing network.
- Line 10 has Alice deploy the application.
The program defined in tut-2/index.rsh will only begin to run after it has been deployed via tut-2/index.mjs.
Line 11 has Bob attach to it.
Lines 14 through 16 initialize a backend for Alice.
Lines 17 through 19 initialize a backend for Bob.
Line 13 waits for the backends to complete.
Line 21 calls this asynchronous function that we’ve defined.
This is now enough for Reach to compile and run our program. Let’s try by running
$ ./reach run
Reach should now build and launch a Docker container for this application. Since the application doesn’t do anything, you’ll just see a lot of diagnostic messages though, so that’s not very exciting.
The entire process that we just went through can be automated by running$ ./reach initwhen you start your next project!
In the next step, we’ll implement the logic of Rock, Paper, Scissors! and our application will start doing something!
Check your understanding: When you write a DApp using Reach, do you
write a smart contract in Solidity, a backend in JavaScript using the Ethereum SDK, and a frontend in JavaScript, then use Reach to test and deploy it;
write a program in Reach that generates a smart contract & a backend and a front-end in JavaScript, then use Reach to test and deploy it?
Answer:2; Reach abstracts away the details of the underlying consensus network