create-react-dapp
create-react-dapp copied to clipboard
Question: why use deployInfo script after migrations?
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 thesrc
folder? This would avoid having to useaxios
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.
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.
@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.
- Adding options for building with other example templates.
- 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
. - Upgrade so that it's fully compatible with
web3
1.0.