create-react-dapp icon indicating copy to clipboard operation
create-react-dapp copied to clipboard

Question: why use deployInfo script after migrations?

Open elie222 opened this issue 6 years ago • 2 comments

I have a bunch of questions around the migration process:

  • Why the need for the deployInfo.js script? Couldn't we have just copied the ABI files that truffle creates and use those?
  • Why not use truffle-contract package?
  • Why put the ABI files into the public folder rather than the src folder? This would avoid having to use axios to make multiple calls for the ABI files.

I mainly ask these questions because I'm interested to learn and potentially contribute to this project in the future. I have some ideas as to why the different decisions were made, but interested to hear what your actual reasons were.

elie222 avatar Apr 05 '18 01:04 elie222

One overall architectural choice for this tool is a clean separation of concerns between the front end development (src folder) and the solidity development (dapp folder). The action of deployInfo.js is the sole bridge between these concerns. Theoretically you should be able to separate the resulting src and dapp folders into separate repos. Then, with a minimal amount of work, you can have two teams working in parallel with minimal conflict or coordination friction.

Why the need for the deployInfo.js script? Couldn't we have just copied the ABI files that truffle creates and use those?

That was my first inclination. The deal killer for that idea was that I needed to combine information from the truffle.js config file with ABI and other information coming out of the compile/migrate process. Theoretically I could pass the responsibility of managing of this information to the browser code, but that means it would need to know too much about the internals of the truffle.js and dapp/build/contact_info/... files and thus violates my goal of separation of concerns.

Why not use truffle-contract package?

Main reason: I didn't know about it until you mentioned it. :) However, even though it looks like a good choice for many projects, my sense is that there are a couple of reasons to avoid it in this project. First it arguably crosses into implementation details of the example code, so it's perhaps out-of-scope for this project. Second, it looks like Web3 1.0 (currently in beta) overlaps with some of the functionality of truffle-contract. So it's unclear to me what the emergent best practice will be.

This is just an inclination, so contrary opinions/arguments are more than welcome.

Why put the ABI files into the public folder rather than the src folder? This would avoid having to use axios to make multiple calls for the ABI files.

This was another "separation of concerns" choice. The public folder is a neutral location for static assets. Putting the contact_info "bridge" files there prevents coupling of the code in the src and dapp folders.

mjhm avatar Apr 15 '18 19:04 mjhm

@elie222 Thanks again for your questions. At very least they made me look back and justify my choices. I've actually been way too busy lately to do all that I've wanted with this project. The main extension ideas that I've thought about are.

  1. Adding options for building with other example templates.
  2. Integrating or coordinating more with truffleframework -- I think this project is a more sustainable approach than Truffle Boxes, because it can automatically incorporate improvements from create-react-app.
  3. Upgrade so that it's fully compatible with web3 1.0.

mjhm avatar Apr 15 '18 20:04 mjhm