We've introduced a regression in 536a4029ba where the default
`value` sent to payable Smart Contract methods is `-1`, resulting in errors as it's not
a valid value.
For payable methods inside of the contract interatction section of cockpit, the value input has been updated to pass wei to the API. The input field now accepts value like `100 ether` or 25 szabo`. The value entered is automatically converted to wei and shown to the user in real time.
Additionally, the input is validated for a correct value, with an error shown to the user for incorrectly entered values.
A tooltip has been added to help the user enter correct values.
UI updates can be seen in video here: https://monosnap.com/file/642cHH2HxDeiFLzB2VLqHP9GuqoRfz
Adjust the API endpoints to augment transaction objects with a timestamp
property from their corresponding blocks. This removes the necessity to copy
the timestamp property from a block to its transactions in the client.
Introduce a `formatTimestampForDisplay` util function in Cockpit for
consistently transforming timestamps into relative or absolute dates, depending
on whether a date is sometime during the last day.
This check was already made when sending messages to whisper channel, however, we didn't
perform the same check when subscribing to channels within cockpit.
When introducing the `embark-api-client` in https://github.com/embark-framework/embark/commit/c1bbdbf34
we didn't properly update Cockpits apiService, resulting in calls to API endpoints
that don't exist.
This commit fixes a bug where calls to Embark's API to subscribe to whisper
channels are in a broken state.
It also updates Cockpit's apiService to no longer pass ignored parameters to embark-api-client.
With the move of Embark's modules into their own packages, the names under
which they are registered in the API service have changed as well.
This caused Cockpit to no longer being able to properly detect whether
ENS is enabled in the current Embark project
Add support for `service api on/off` commands.
Deprecate commands `api start/stop` in favor of `service api on/off`.
`service api on` - Enables the API server serving Cockpit. Shows an error if the API server is already starting or started.
`service api off` - Disables the API server serving Cockpit. Shows an error if the API server is already stopping or stopped.
`api start` - This command has been deprecated in favor of `service api on` and will be removed in future versions.
`api stop` - This command has been deprecated in favor of `service api off` and will be removed in future versions.
`api:start` - This event has been deprecated and will be removed in future versions.
`api:stop` - This event has been deprecated and will be removed in future versions.
In addition to introducing improvements per #1492 and #1494, adjust the
transactions request action to allow for a `blockLimit` argument, since that
API parameter is supported by embark.
Revise `changePage` to invoke `fetchTransactions` correctly, i.e. with
arguments pertaining to a starting block number and a block limit.
These changes together fix most of the pagination problems related to exploring
transactions, i.e. badly mis-ordered results are no longer displayed.
However, a *wart* still remains related to estimation of the total number of
transactions and pages. Sometimes the calculated number of pages for the
transactions explorer doesn't match up to the actual number of transactions on
the blockchain (owing to estimation). The pagination controls and display of
transactions will temporarily behave a little strangely if one jumps ahead in
the pages, e.g. a jump from cockpit explorer overview's transactions page 1 to
page 5 for embark's demo, if an additional transaction has been added and the
explorer overview is freshly loaded. This behavior is related to the fact that
actions such as `fetchBlocksFull` and `fetchTransactions` are async without any
means to determine when all actions have completed and React re-/rendering has
settled down.
There are probably some architectural changes that could improve the situation,
but they're outside the scope of this PR and in no way easy to solve by means
of React lifecycle methods. In fact, attempts to make an improvement with
`componentDidUpdate` (and watching what happens in the debugger) revealed the
nature of the problem, as described above.
`webSocketProcess` function in `embark-api-client` expects only a process name,
but cockpit was calling it with name-strings prepended with `/process-logs/`
resulting in bad URLs. Revise cockpit's `services/api` module to call
`webSocketProcess` with process names only.
Create a dev tx (a 0-value tx that is sent from the —dev account to itself) when a request goes through the proxy, but does not get a response after 5 seconds.
Log requests to disk (when log level is trace - enabled with the embark option `—loglevel trace`) that have not received a response and for which a dev tx has been sent.
Add logging to a `proxyLogs.json` log file as well, so that this information can be gleaned later for debugging purposes.
This particular PR Is meant to workaround an issue with running geth with the `—dev` option, as some transactions appear to get stuck, which then builds up further txs in a queue. Only when another tx is sent is the queue then purged as expected.
The remaining issue is that even though a dev tx is sent to relieve the queued txs, the originally offending tx still never receives a response from the node. This was the motivation behind creating a proxy log, so that a dev can inspect the txs that are essentially dropped.
**NOTE:** the base branch of this branch is `refactor/devfunds`. Please merge that branch first.
Change name “DevFunds” to “DevTxs”.
Remove unused functions in dev_funds (create accounts, unlock accounts, fund accounts).
Add console command `sendtx` to send a one-off dev transaction.
Modify the dev tx to send a 0-value tx to itself (ie the `web3.eth.defaultAccount` which is the `—dev` account).
Deprecate the command `regularTxs on/off` in favour of `devtxs on/off` (notice the casing).
Strip regulartxs from cockpit and modify the browser warning to instruct users to run a console command.
This commit has been originally cherry-picked from d0d89fc5ae and
slightly modified to update all packages, as meanwhile, new packages have been added to `master`.
The reason this commit is cherry-picked from `4.0.x` branch is because
it wasn't created from `master`.
Purpose is mainly to update `CHANGELOG` and get the package versions in sync again.
Display five contracts per page in the dashboard. Display ten contracts per
page in the contracts explorer and deployment page.
Sort contracts by name. In the future we can implement an option to sort by
block number and index within a block by calculating and including that
information as part of the server-side api response (based on a contract's
txhash).
Remove unnecessary contract filtering in the components since the containers
take care of it.
Make use of `listenToContracts` / `stopContracts` in DeploymentContainer.
During work on PRs #1492 and #1494 it became evident that it's not desirable to
show pagination controls unless the number of pages is greater than one.
Display a truncated account balance if the balance is greater than 20
characters in length. This keeps the "Balance", "Tx Count", and "Index" fields
well-aligned in lists of accounts.
In the account details page continue to show the full balance.
Display two accounts per page in the explorer overview. Display ten accounts
per page in the accounts explorer page.
Sort accounts by their api-supplied index numbers with the lowest index coming
first.
Change the `initBlockHeader` saga so that it triggers a re-fetch of accounts
and therefore the "Tx Count" numbers of displayed accounts will reflect
increased counts.
Make tabs draggable so they can be arranged how the user would like.
The dragging functionality locks the tabs to the parent container.
Support for multiple rows of tabs.
Styling updates for selected tabs.
When connected to metamask, and “Injected Web3” is selected on the Deployment page of Cockpit, check to see if contracts have already been deployed or not.
For contracts that have not been deployed, or set to an address in the config, these should now all be re-deployable.
Supports libraries (that have bytecode with `0x73<address><bytecode>`).
TL;DR
=====
Unregister (disable) the service worker in production builds of Cockpit. The
CRA dev server doesn't enable the service worker, so no changes are needed in
that context, i.e. `yarn start` in the monorepo.
**NOTE**: to effect these changes a user will need to load production Cockpit at
`localhost:55555` and then close all Cockpit tabs (or restart the
browser). This should be done for each browser that has been used to access
production Cockpit. See the *Step-by-Step* section below for more information.
Rationale
=========
There are a couple of factors:
* It's a bit confusing that after stopping `embark run` the production build of
Cockpit is still accessible at `localhost:55555`. That's owing to CRA's
[offline-first behavior][PWA] per the service worker it creates, which
Cockpit [currently registers][current] (enables).
* It can be really confusing, if you don't know or forget about the service
worker's behavior, that after a production rebuild of Cockpit the old build
is still used in the browser, even after a page refresh. As [explained][ofb]
in CRA's docs: *"users will end up seeing older content until they
close (reloading is not enough) their existing, open tabs."* A similar effect
is seen when switching between DApps, e.g. teller and embark_demo.
The CRA docs point to [some code][code] that could be adapted to an alert in
the UI prompting the user to close all tabs and reopen the app. That approach
definitely makes sense for DApps built with CRA that have opted-in to the
service worker. In fact, the service worker behavior would be critical in DApps
that make use of connected-/react-router because cold loads of routes that
don't actually correspond to static files couldn't otherwise work, i.e. if the
DApp is being served from ipfs/swarm.
But for Cockpit itself, when served from localhost with an express backend that
we control, little seems to be gained from offline-first behavior vs. a more
familiar behavior, i.e. when `embark run` isn't running then Cockpit isn't
accessible.
Step-by-Step
============
Flushing a site's service worker from cache can be tricky. The following steps
outline an approach to making sure the Cockpit in use is the one with service
worker disabled.
1. The first screenshot below shows the JavaScript console from a fresh load of
Cockpit with the service worker enabled, i.e. from a build on `master` at time
of writing and `embark run` running for the `embark_demo`. Note the messages
re: *"workbox"* and *"precaching"*.
![][step-1]
2. The next screenshot shows what happens when `embark run` is stopped and the
browser is refreshed. Service worker makes the page available offline, though
there are errors related to embark's API not being accessible.
![][step-2]
3. (a) Cockpit gets rebuilt on this PR's `refactor/cockpit-service-worker`
branch and `EMBARK_UI_STATIC=t embark run` is started; see [previous
commit][prevcom] re: `EMBARK_UI_STATIC`. (b) The browser is refreshed. Note the
message at the bottom re: *"New content is available"*.
![][step-3]
4. The Chrome browser is closed completely (command-Q), reopened and
`localhost:55555` is loaded again. Note there are *still* messages re:
*"workbox"* and *"precaching"*.
![][step-4]
5. The page is refreshed again and now the messages are completely gone.
![][step-5]
6. `embark run` is stopped and the page is reloaded, but there's a connection
error because no process is listening on `localhost:55555` — proof that
the service worker is no longer in play!
![][step-6]
Steps 3(b) to 6 will need to be repeated for each browser (Firefox, Safari,
etc.) that visited `localhost:55555` when the service worker was enabled. And
they'll need to be repeated again if the browser is later used with a build of
Cockpit predating this PR.
[PWA]: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
[current]: 4d4704ac6f/packages/embark-ui/src/index.js (L39)
[ofb]: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app#offline-first-considerations
[code]: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/src/serviceWorker.js#L66-L93
[step-1]: https://user-images.githubusercontent.com/194260/54885199-adfa0900-4e47-11e9-830b-1b92816b2354.jpg
[step-2]: https://user-images.githubusercontent.com/194260/54885202-b3575380-4e47-11e9-9c1e-24817472d9c4.jpg
[step-3]: https://user-images.githubusercontent.com/194260/54885209-bb16f800-4e47-11e9-8e23-8fbc3b4f48fa.jpg
[prevcom]: https://github.com/embark-framework/embark/commit/322033cc
[step-4]: https://user-images.githubusercontent.com/194260/54885212-bfdbac00-4e47-11e9-9c8c-db90228d953a.jpg
[step-5]: https://user-images.githubusercontent.com/194260/54885214-c538f680-4e47-11e9-9963-58fd041675f0.jpg
[step-6]: https://user-images.githubusercontent.com/194260/54885217-ccf89b00-4e47-11e9-967a-7f8a523d4a92.jpg
When a fallback function is encountered give its signature as `function()`,
disable row expansion, and omit the interaction form. Also label with a
`fallback` badge.
Create React App automatically determines the base path for links within
production build artifacts based on the project's `"homepage"` field in
`package.json`.
An [alternative][alt-setting] is to set the `PUBLIC_URL` environment variable
in `.env.production`. Take that approach so embark-ui's `"homepage"` can
continue to point to its home in the monorepo on GitHub.
Generate source maps in the production build of embark-ui. Doing so increases
the size of the package's tarball by a few MB (it was already large because of
the editor component), but the benefits of being able to much more easily debug
a production build (e.g. when interacting with users experiencing problems)
outweigh the size cost.
[alt-setting]: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/paths.js#L36
Don't implicitly rely on explorer overview having been loaded to initially
populate `entities.transactions`. Also, that container should watch for new
blocks/transactions same as the other explorer containers.
Restore `fetchTransactions` and related to TransactionsContainer. It's no
longer the basis of pagination (it didn't work as desired), but when navigating
through the transaction pages that action will ensure more transactions are
fetched so that the account page will list more of an account's transactions
over time. That was a side effect of `getTransactions` before it was removed in
favor of `getBlocksFull`, which is still the basis of revised pagination logic
in the transactions explorer.
Revise calculations related to transactions and pagination in the transactions
explorer and explorers overview.
Make the number of transactions to display per page configurable and set it to
3 in the explorers overview. Display a "No transactions..." message instead of
"0" when there are no transactions to display.
Introduce a `blocksFull` prop, action, api, etc. for calculating lists of
transactions relative to block objects that contain full transaction objects
instead of hash strings (the function backing the blocks endpoint already
supports that) and transaction receipts. In the future, the receipts can be
used to filter out constructor transactions for silent contracts.
Make pagination display conditional within the blocks explorer, same as in the
transactions explorer.
Filter silent contracts in the views that display contracts lists rather than
with `formatContractForDisplay` because the old approach prevents interaction
with a silent contract if a link to it is followed from the blocks or
transactions explorer, which is not desirable.
Rename contract "Transactions" tab to "Log". Display and allow filtering of all
contract methods. Disable debug button for pure/view functions and the
constructor.
Revise the filtering logic so that filters are combined together. Make the
status filter a drop down menu like the others.
Revise styling for consistent row height, alignment of text, and button sizes;
use a monospaced font in some cases to achieve the effect.
Handle enter/return correctly in forms within a contract's Interact tab.
Remove event rows from a contract's Interact tab.
Track pure/view calls in the blockchain proxy so they can be logged server-side
by console listener and reported in Cockpit within a contract's Log tab.
Eliminate double logging in the contracts manager. Ensure contracts deployed on
a fresh `embark run` have an `address` / `deployedAddress` property.