search

stellar / soroban-example-dapp

End-to-End Example Soroban Dapp
Apache License 2.0
1.03k stars 830 forks source link

build: update for preview 11 #136

Closed chadoh closed 9 months ago

chadoh commented 9 months ago
sreuland commented 9 months ago

@chadoh , can probably use the latest commit off quickstart:master of b58a1127ada30a477f49f330e21038426fb272e4 , also, the network config here could now allow running against testnet as well since it's on soroban/p20.

Julian-dev28 commented 9 months ago

Just tried this out. Everything is working an no issue to report!

Julian-dev28 commented 9 months ago

Just tried this out. Everything is working an no issue to report!

I want to point out that I initially tried this out on futurenet which worked with no issues to report. However, after trying it again on standalone, I ran into the error: 'xdr processing error: xdr value invalid.'

sreuland commented 9 months ago

@chadoh , can probably use the latest commit off quickstart:master of b58a1127ada30a477f49f330e21038426fb272e4 , also, the network config here could now allow running against testnet as well since it's on soroban/p20.

I replied here for the quickstart docker version which you were probably more interested in.

on the 'testnet' enablement, that would be adding it as another network choice in initialize.sh and quickstart.sh.

also, in regards to using the preview11 quickstart version, it has deprecated the usage of --standalone in favor of --local instead now, it will print a warning for the former usage. so, it may be good to adjust terminology here to be consistent, i.e. replace 'standalone' with 'local' or should we carve that out to separate ticket?

chadoh commented 9 months ago

I do think that changing all the language from quickstart to local or localnet is a separate issue. Partly because I'm not clear on what the new name is. Just local? Or localnet? Or does it depend on context? Seems like a bike-shed-type change that doesn't need to slow this one down.

I would also prefer the addition of testnet to the options here be a separate PR, too. Is that ok? This one was just meant to get things working with the latest Futurenet, as quickly as possible.

I updated the quickstart image in https://github.com/stellar/soroban-tools/pull/973 and here, and I switched the --standalone flag to --local in the quickstart.sh script. However, you can see that the change to the CLI has a failing build:

Error: Failed to initialize container stellar/quickstart:testing@sha256:1c98f895f8b69cc843eeaa5230d67044dbeb390a5529d51dd7762d8ff685c3f8
sreuland commented 9 months ago

I would also prefer the addition of testnet to the options here be a separate PR, too. Is that ok? This one was just meant to get things working with the latest Futurenet, as quickly as possible.

@chadoh , thanks sounds good.

I updated the quickstart image in https://github.com/stellar/soroban-tools/pull/973 and here, and I switched the --standalone flag to --local in the quickstart.sh script. However, you can see that the change to the CLI has a failing build:

ok, will try out locally, we just need to verify initialize&run of dapp for local and futurenet network types correct?

sreuland commented 9 months ago

@chadoh , that format error from gh workflow is a platform discrepancy of host and image, that sha is pointing at wrong image version actually, you can see earlier in the logs of it downloading the image it reports the issue WARNING: The requested image's platform (linux/arm64) does not match.

So, that's one issue, which needs to get fixed in soroban docs also, as it should be the multi-platform sha instead and needs to be updated to newer build anyways, because, I'm trying the pr locally on an arm64 host for the standalone network, where that image gets past format errors, but errors for real on contract deploys during init due to resource limits on the local network fromquickstart:testing image, the latest build of stellar/quickstart:soroban-dev actually has more recent changes to disable resource limits on that image per https://github.com/stellar/quickstart/pull/492, so, should grab that, and change QUICKSTART_SOROBAN_DOCKER_SHA=stellar/quickstart:soroban-dev and add --pull always to the docker run command in quickstart.sh to make sure getting the latest, this will also allow docker to pull the correct platform image automatically.

I've manually installed latest cli - cargo install soroban-cli@20.0.0-rc4 --root ./target

With that in place , i'm able to run ./quickstart.sh standalone and then NETWORK=standalone npm run reset , init logs that it used my cli -Using soroban binary from ./target/bin and contracts are built/deployed.

but when I run the server - npm run dev i get a js error in browser:

Screen Shot 2023-09-26 at 2 17 55 PM
chadoh commented 9 months ago

@sreuland this one should be working now

sreuland commented 9 months ago

@sreuland this one should be working now

@chadoh , I tried latest from pr, it's initializing correctly but the dapp in browser is getting different js error:

I did in one terminal:

./quckstart.sh standalone

and in second terminal:

rm -rf ./node-modules
npm install
NETWORK=standalone npm run reset
npm run dev

in browser i get:

Screen Shot 2023-09-28 at 12 51 24 PM
sreuland commented 9 months ago

@chadoh , I tried latest from pr, it's initializing correctly but the dapp in browser is getting different js error:

@chadoh , I think this error was due to the local 'target' directory on my machine not being wiped as part of dapp init steps so, some older contract was in there, and bindings got generated from that, or at least after purging the target directory and init'ing dapp from npm reset again, this forced new cli, ontract wasm, contract bindings from the wasm to be re-built regardless, and eliminated the error on ts gen code saw earlier, and the dapp loads now.

During investigation, I tried following the steps in README for how to init, and it gets pretty complex with different instructions for different networks, so, I took a small step back and tried to consolidate dapp init to always just be npm run reset, to avoid any old state between dapp restarts, etc and a single way to init regardless of network type.

I put up PR with these suggestions based on your build/preview11 branch, in case you agree the suggestions and want to pull in. AhaLabs/soroban-example-dapp/pull/1

Julian-dev28 commented 9 months ago

@chadoh , looks good, I just tested out standalone and futurenet back to back, and both cases worked, the only thing I found was the 'clean' behavior between resets and put up a pr with a suggestion - AhaLabs/soroban-example-dapp/1

Just tested both cases back to back as well and can confirm this is working