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 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 =
 4      Reach.App(
 5        {},
 6        [Participant('Alice', {}), Participant('Bob', {})],
 7        (A, B) => {
 8          exit(); });

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.

• Line 6 specifies the two participants to this application, Alice and Bob.

• Line 7 binds Reach identifiers (A and B) to these participants and defines the body of the program.

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    
 4    (async () => {
 5      const stdlib = await loadStdlib();
 6      const startingBalance = stdlib.parseCurrency(10);
 7    
 8      const accAlice = await stdlib.newTestAccount(startingBalance);
 9      const accBob = await stdlib.newTestAccount(startingBalance);
10    
11      const ctcAlice = accAlice.deploy(backend);
12      const ctcBob = accBob.attach(backend, ctcAlice.getInfo());
13    
14      await Promise.all([
15        backend.Alice(
16          ctcAlice,
17          {},
18        ),
19        backend.Bob(
20          ctcBob,
21          {},
22        ),
23      ]);
24    })(); // <-- 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 4 defines an asynchronous function that will be the body of our frontend.

• Line 5 loads the standard library dynamically based on the REACH_CONNECTOR_MODE environment variable.

• Line 6 defines a quantity of network tokens as the starting balance for each test account.

• Lines 8 and 9 create test accounts with initial endowments for Alice and Bob. This will only work on the Reach-provided developer testing network.

• Line 11 has Alice deploy the application.

• Line 12 has Bob attach to it.

• Lines 15 through 18 initialize a backend for Alice.

• Lines 19 through 22 initialize a backend for Bob.

• Line 14 waits for the backends to complete.

• Line 24 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 init

when 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

1. 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;

2. 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