Fixed issue with contract deploying for first time and having no gasLimit specified.
Optimised/refactored looping of compiled contracts.
Added body parameter type checking for `/embark-api/contract/deploy` endpoint
Handle use cases:
1) handle case when temp.sol doesn’t exist - due to the new saga updates, the response from retreiving a temp fiddle from the filesystem (even if it doesn’t exist) is forward to the compilation endpoint, which returns an ENOENT, and this is handled in the selector.
2) delete all code - shouldn’t return last fiddle and should compile an empty string.
3) Switch to different tab (ie contracts) then back to fiddle - previous fiddle should remain.
Also fixed an issue (most likely due to latest rebase) when deploying fiddle contracts. The gasLimit was not being specified.
Handled issue where entities stored in the state were not being put in the correct order, so a timestamp was sent with the requests and then sorted when the response was returned.
1) hanlde case when temp.sol doesn’t exist
2) delete all code - shouldn’t return last fiddle
3) Switch to different tab (ie contracts) then back to fiddle - fiddle should now remain.
Fiddles are now stored in the filesystem so they can be preserved across page reloads, but also so that contracts deployed via fiddles can have their source code shown.
Fiddles deployed as contracts now fully work with existing contract list UI and functionality. Fiddle deployed contracts are listed in a separate section in the UI.
Current limitation is that only single contracts per file are supported. If the fiddle contains multiple contracts, it’s currently not supported.
Fiddle is properly deploying now, except the source code needs to be saved to the filesystem in order to be recalled later.
Fixes for handling errors on deploy and compilation.
Update contract state UI for determining state / interface / deployed.
Fixed browser errors caused by tabler (bodyItems and headerItems complaints) as well as staticContext issues caused by using withRoute(NavLink)
Also added a response to fiddler deployment.
Added loading states to fiddler results, that shows the errors/warnings as having a loading state when compiling/deploying
Changed `fiddle` to an entity and removed unneeded fiddle reducer.
Added a selector for getting the entity.
Changed fiddle saga to `doRequest`.
Changed fiddle api call to the `post` method (did not see beofre the rebase).
Added `CompilerError` presentation component to handle displaying compiler errors and warnings.
Added spaces to css (as requested).
Removed extra space after function in solidity compiler (as requested).
Removed the compile contract event from the solidity compiler (as requested).
Handling of fatal api error in the UI.
Changed fiddle action to the one created with `createRequestTypes`.
Moved `Fiddle` nav tab before `Documentation`.
Changed `FiddleResults` DOM manipulation to be controlled via React state instead.
Compiler annotations added to editor gutter for errors and warnings
Clicking an error now scrolls editor to offending line and scrolls page to the top of the editor
Added Compiling… loader.
- Booleans weren't being sent correctly (it always assumed true)
- Booleans now are shown on the results
- Handling result visualization when there's more than one parameter
- UI shows error screen if contract doesn't exist or fails fetching data
- Menu shows selected state and icons can be specified
- Component created for card alerts
Changed the online event to `once` and set it to be bound every time the node goes offline.
The above changes handle the case where:
1) `embark run` runs and starts geth.
2) geth is killed manually
3) `embark blockchain` is run in separate process to restart geth
4) the `embark run` process detects this change and restarts the web3 provider and recompiles/deploys/builds
Every time `embark blochain` is restarted, an error is appended and all are emitted from the `eth-block-tracker`. This is a bug but can't figure out where it originates. The downside is that if, for example, `embark blockchain` is restarted 4 times, there will be 4 errors emitted from the `eth-block-tracker`. Because of this, errors emitted from `eth-block-tracker` have been reduced to trace to avoid clogging the logs.
First case - run `embark run` which starts a blockchain node, then manually kill the `geth` process. Would throw `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` error and ruins the dashboard.
Second case, 1) run `embark blockchain` 2) run `embark run` 3) kill `embark blockchain` throws the error `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` and ruins the dashboard.
The first case was solved by having the child blockchain process that spawns geth listen for geth exit, then kill itself.
The second case required updating of `eth-block-tracker` to v4.0.1 inside of the `embark-web3-provider-engine`. v4.0.1 was a major version update and introduced breaking changes. Those changes were handled inside of `embark-web3-provider-engine`, covered in **blocker** PR https://github.com/jrainville/provider-engine/pull/1.
Jonathan Rainville
Anthony Laibe
emizzle
Iuri Matias
Richard Ramos
Michael Bradley, Jr
RJ Catalano