Add support for ability to start and stop Swarm via command `service swarm on/off`.
Fix issue with swarm not starting due to missing web3 object.
`service swarm on` - starts a swarm node if not already started. Shows an error if the node is already starting or started.
`service swarm off` - kills the running swarm node as long as Embark has started the swarm process. If the swarm process was started externally, an error is shown.
We lost this when we moved the site into the monorepo because
all `dist` folders were ignored.
Co-Authored-By: PascalPrecht <pascal.precht@googlemail.com>
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.
Add support for ability to start and stop IPFS via command `service ipfs on/off`.
Add support for `ProcessState.Errored` process state in the `ProcessManager`. This allows for processes being launched and stopped to trigger an error and the resulting process will be in an errored state. Processes in errored states can still attempt to be started and stopped.
`service ipfs on` - starts an IPFS node if not already started. Shows an error if the node is already starting or started.
`service ipfs off` - kills the running IPFS node as long as Embark has started the IPFS process. If the IPFS process was started externally, an error is shown.
return early
We could use similar comments for imports related to other `@types` packages,
but the need to do it for `@types/embark` (located in
`packages/embark-typings`) seems more pressing since `import ... from "embark"`
statements in the monorepo can be so easily misunderstood.
Note that the comments, and indeed the whole lines, are automatically erased
during babel transpilation of TypeScript since TS types aren't relevant after
the `.js` files are built.
If a package uses only `.js` then supply `--extensions ".js"`. If a package
uses only `.ts` then supply `--extensions ".ts"`. If a package uses both, then
supply `--extensions ".js,.ts"`.
The reason for this is that adding/removing TS/JS support ought to occasion
revising a package's `package.json` file and adjusting other scripts as well,
e.g. for linting. With these changes, it won't work to simply start adding
`.ts` files in a package's `src/` directory, which should prompt the developer
to review `package.json` and make the appropriate changes, and/or other
developers may realize changes need to be made during code review.
Jonathan Rainville
Michael Bradley, Jr
emizzle
Pascal Precht
yanqian
Andre Medeiros
Sebastian Mueller
Iuri Matias