Origin: Developer onboarding: One line setup

[wanderingstan]

The steps to get started with _demo-dapp_ are currently long and tedious. (A similar issue is open for _origin.js_)

See current instructions here: https://github.com/OriginProtocol/demo-dapp#install-and-run-demo-dapp-locally

We need a friendlier intro for new contributors, and a system that is less error-prone.

• Drop truffle develop and use ganache-cli to run local blockchain. (Using build scripts by @nick as inspiration)
• Use env and/or command line args to switch between local chain and network chains. (E.g. Rinkeby, mainnet)

Other ideas?

@joshfraser @DanielVF @tyleryasaka @micahalcorn

---

EDIT: A more specific goal for us:

Primary Goal: User can have dapp up and running with one line (after cloning).

git clone [email protected]:OriginProtocol/demo-dapp.git && cd demo-dapp

npm install && npm run start

• Should work from default branch shown to user on https://github.com/OriginProtocol/demo-dapp
• Should launch a browser running the dapp, using latest compatible origin.js from npm
• Should function on Rinkeby and Ropsten testnets.
• Target audience is front-end js and react developers who want to build Origin DApps, but don't know (or need to care) about blockchain.

[nick]

Personally I'm a fan of removing truffle altogether, upgrading to web3 1.0 and having MetaMask as opt-in rather than required.

• Less dependencies
• Support for Safari, IE, Mobile and React Native
• Instant test results
• Easier developer on-boarding
• Future proof

[wanderingstan]

Truffle
Are there any positives on truffle? It apparently has some features around handling migrations of contract updates, but I've never used them.

Everything else we use it for can be handled by solc and ganache-cli?

Metamask
It would definitely be amazing if Metamask (or other web3 provider) was not a requirement. @nick , are you suggesting we have logic that looks for a web3 object and if none is found, will inject a browser-based wallet like you have in identity-playground? We would want to make sure that an injected web3 (as from Toshi or Cypher) would always have priority. (Perhaps with option within dapp to switch)

[nick]

Truffle has come wrappers around contract objects to make them 'easier' to use, but since that's essentially what origin.js is also doing I think skipping a dependency could be beneficial. It also means no more waiting for truffle to update if there are new solidity features we want to use.

I think https://idex.market has a good UI for wallet management, whereby MetaMask is available as an option but not required.

[wanderingstan]

I think we should move the "remove truffle" discussion to it's own issue, as it's a big change and beyond the scope of this issue.

Switching to ganache-cli (from truffle develop) is required for having a clean one-line-setup, so I think that's a no-brainer.

[wanderingstan]

For discussion around working with Truffle without Metamask, this issue is the right place: https://github.com/OriginProtocol/demo-dapp/issues/80

[jsulinski]

@wanderingstan #80 is working without metamask. Perhaps create a new issue for removing truffle and keep this one for improving the onboarding flow?

For what it's worth, I came to the same conclusions regarding moving away from Truffle.

To add to @nick's list:

• Issues with builds require deleting the ./builds directory [1] [2]
• lacks full support for events involving more than one contract [3]
• sometimes uses trailing versions of web3.js [4]
• doesn't support getting a transaction hash before mining, which web3.js does support [5] [6]

[1] https://github.com/trufflesuite/truffle/issues/596
[2] https://github.com/trufflesuite/truffle/issues/693
[3] https://github.com/trufflesuite/truffle/issues/555
[4] https://github.com/trufflesuite/truffle-contract/pull/95/commits
[5] https://github.com/trufflesuite/truffle-contract/issues/100
[6] https://github.com/trufflesuite/truffle-contract/issues/42

[wanderingstan]

Thanks @jsulinski ! (Fixed the wrong description around #80 )

I've create an issue on _platform_ for discussion around removing truffle:
https://github.com/OriginProtocol/platform/issues/94

[nsimon]

I've been experimenting with some bash one-liner scripting for demo-dapp. It seems like this could (should?) be 2 separate scripts -- an installer and a startup. As an example, here's a startup gist I've been playing with.
https://gist.github.com/nsimon/78d2e33abb9ca0dbdf215d64c27e2c82

[wanderingstan]

I'm realizing the issue should be worded more concretely:

Primary Goal: User can have dapp up and running with one line (after cloning).

git clone [email protected]:OriginProtocol/demo-dapp.git && cd demo-dapp

npm install && npm run start

• Should work from default branch shown to user on https://github.com/OriginProtocol/demo-dapp
• Should launch a browser running the dapp, using latest compatible origin.js from npm
• Should function on Rinkeby and Ropsten testnets.
• Target audience is front-end js and react developers who want to build Origin DApps, but don't know (or need to care) about blockchain.

Use demo-dapp with local chain?
Actually, I don't see how we can do this without the user cloning the platform repo as well. But that doesn't seem to bad, because there should be no need to run local chain unless you intend to work on origin.js or our smart contracts.

Developing with Platform repo
More discusson on platform "one-line" issue: https://github.com/OriginProtocol/platform/issues/89

Random thoughts:
Could we make a "developer-dapp" repo that includes both demo-dapp and platform, and automagically does the npm linking? Or would this just be more confusing?
Or is the a place where a bash script would be the simpler solution?
Or could we make demo-dapp a devDependency of platform? (So people working on platform automatically have demo dapp?)

[tyleryasaka]

1. Use demo-dapp with local chain?

I think if someone is just working on the demo dapp, then yes we should make it easy to just use a test net rather than having to run a local blockchain.

1. Developing with Platform repo

I also thought about creating a develop repo or something of the like. I think this will cause more harm than good. Would be too many repositories, too confusing. We also want to keep in mind, that people might be forking our demo dapp and trying to create their own unique marketplaces (that's kind of why we're building all of this in the first place). Ideally they should just be able to fork our demo dapp and follow the same process for developing that.

Here's what I'm thinking:

demo dapp instructions

I think we should provide 2 sets of instructions - one for using test net, and another for using local chain (which will require an extra step to set up platform repo locally).

Using test net would just be npm install/npm start. (Maybe throw in a flag to tell node that we want to use a test net)

Using local chain, instructions would be:

1. Clone platform repo and follow platform setup instructions (these would be in platform readme; see below)

2. Start platform (npm start from inside platform repo)

3. npm setup (or something like that) from demo-dapp. Shorthand for npm install && npm link @originprotocol/origin.

4. npm start:local (or something like that) from demo-dapp

In other words, doing local blockchain development would require 2 terminal tabs and basically duplicating commands in each repo. Initial setup would be 2 commands in each repo; after that, would just be npm start in each repo.

It's basically an extra command and an extra terminal tab, but for the price of that extra command, it's a lot more transparent to the developer what they're doing, and kind of cleanly separates the platform which is serving the blockchain from the demo dapp that is just client side. Just the same way that you would have separate repos/terminals for running server and client simultaneously.

platform instructions

1. npm setup (just Shorthand for npm install && npm link)
2. npm start (would start ganache, deploy initial contracts, build JS and then watch everything for changes)
3. Mention that the developer can run tests for pure test-driven development, or that they can use the demo dapp to test out the platform, and then provide a link to the demo dapp repo.

[micahalcorn]

@tyleryasaka this is done via #108, yeah?

[tyleryasaka]

@micahalcorn Yes this is done 😃