Phoenix is a framework agnostic JS library that embraces reactive programming with RxJS, by observing asynchronous changes in Smart Contracts, and providing methods to track and subscribe to events, changes to the state of contracts and address balances, and react to these changes and events via callbacks.
All the tracked information is stored in a local database (or localStorage in the case of web applications), meaning the user can resume data synchronization starting from the last block synchronized locally.
-`dbFilename` - Name of the database where the information will be stored (default 'phoenix.db')
-`callInterval` - Interval of time in milliseconds to query a contract/address to determine changes in state or balance (default: obtain data every block).
Phoenix provides tracking functions for contract state, events and balances. These functions return RxJS Observables which you can subscribe to, and obtain and transform the observed data via operators.
Reacts to contract state changes. Using this method, you can track changes to the contract state, by specifying the view function and arguments to call and query the contract.
This can be used as well to track public state variables, since they implicity create a view function when they're declared public. The `functionName` would be the same as the variable name, and `functionArgs` would have a value when the type is a `mapping` or `array` (since these require an index value to query them).
Reacts to changes in the balance of addresses. This method can help track changes in both ETH and ERC20 token balances for each mined block or time interval depending on the `callInterval` configured. Balances are returned as a string containing the vaue in wei.
You may have noticed that each tracking function has a `.subscribe` chained to it. Subscriptions are triggered each time an observable emits a new value. These subscription receive a callback that must have a parameter which represents the value received from the observable; and they return a subscription.
Subscriptions can be disposed by executing the method `unsubscribe()` liberating the resource held by it:
If Phoenix `eventSyncer` is not needed anymore, you need to invoke `clean()` to dispose and perform the cleanup necessary to remove the internal subscriptions and interval timers created by Phoenix during its normal execution. Any subscription created via the tracking methods must be unsubscribed manually (in the current version).
Phoenix does not force you to change the architecture of your dApps, making it easy to integrate in existing projects. Here are some pointers on how to integrate Phoenix with various frontend frameworks:
The `observe` HOC is provided to enhance a presentational component to react to any phoenix event. This HOC subscribes/unsubscribes automatically to any observable it receives via `props`.
Phoenix can be configured in epics created with [redux-observables](https://redux-observable.js.org/). It's recommended to compose these epics by using [mergeMap](https://www.learnrxjs.io/operators/transformation/mergemap.html) or [switchMap](https://www.learnrxjs.io/operators/transformation/switchmap.html) operators
// If addTypename:true, the query will fail due to __typename
// being added to the schema. reactive-graphql does not
// support __typename at this moment.
cache: new InMemoryCache({ addTypename: false }),
link: PhoenixRxLink(schema)
});
this.setState({ client });
<ApolloProviderclient={this.state.client}>
<Queryquery={MY_QUERY}>
{({ loading, error, data }) => {
if (loading) return <div>Loading...</div>;
if (error) {
console.error(error);
return <div>Error :(</div>;
}
return (
<p>The data returned by the query: {JSON.stringify(data)}</p>
);
}}
</Query>
</ApolloProvider>
```
## Contribution
Thank you for considering to help out with the source code! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
If you'd like to contribute to Phoenix, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on #embark-status channel to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.