If someone fills (fully or partially) an order that belongs to the connected user, a notification is shown indicating what kind of order was filled, and how much.
Implementation
A callback is registered using the ExchangeWrapper.subscribe method, filtering the ExchangeFill events whose makerAddress corresponds to the connected user. In other words: each time an order created by the connected user is filled, the callback is called. This callback dispatches a notification. The logic that builds this notification from the information of the event is in the buildOrderFilledNotification function.
I added a new action: setConnectedUser. This action is called to set the address of the current user, and it's where the subscription is created. This has a problem: if the action is called twice, a new subscription will be created. Since we reload the page when the user is changed, this is not a problem now, but it would be nice to make this more resilient.
An alternative to this was registering the suscription in the root component. The problem with this approach was that, when this component is rendered, the ethAccount is empty (the blockchain state is not created yet). So we would need to wait until the redux-connected ethAccount prop is changed to a non-empty value. This is messy (you have to use a deprecated lifecycle hook or do it in the render function), so I opted for doing this in the action where the ethAccount is set.
You'll see that the initializeBlockchainData action now accepts a Partial<BlockchainState>, since the ethAccount is not passed to it anymore.
Test factories
I added the factory.ts library to have data factories for the tests, since creating a lot of tokens was getting annoying. I only created two factories: one for addresses and another for token metadata. Later we can add others for things like orders or plain tokens.
It seems like factories can only build objects, not plain values like strings. That's why the address factory returns a {address: string} object. Very annoying, maybe we can have a wrapper around it that just returns the string.
If someone fills (fully or partially) an order that belongs to the connected user, a notification is shown indicating what kind of order was filled, and how much.
Implementation
A callback is registered using the
ExchangeWrapper.subscribe
method, filtering theExchangeFill
events whosemakerAddress
corresponds to the connected user. In other words: each time an order created by the connected user is filled, the callback is called. This callback dispatches a notification. The logic that builds this notification from the information of the event is in thebuildOrderFilledNotification
function.I added a new action:
setConnectedUser
. This action is called to set the address of the current user, and it's where the subscription is created. This has a problem: if the action is called twice, a new subscription will be created. Since we reload the page when the user is changed, this is not a problem now, but it would be nice to make this more resilient.An alternative to this was registering the suscription in the root component. The problem with this approach was that, when this component is rendered, the
ethAccount
is empty (the blockchain state is not created yet). So we would need to wait until the redux-connectedethAccount
prop is changed to a non-empty value. This is messy (you have to use a deprecated lifecycle hook or do it in the render function), so I opted for doing this in the action where theethAccount
is set.You'll see that the
initializeBlockchainData
action now accepts aPartial<BlockchainState>
, since theethAccount
is not passed to it anymore.Test factories
I added the
factory.ts
library to have data factories for the tests, since creating a lot of tokens was getting annoying. I only created two factories: one for addresses and another for token metadata. Later we can add others for things like orders or plain tokens.It seems like factories can only build objects, not plain values like strings. That's why the address factory returns a
{address: string}
object. Very annoying, maybe we can have a wrapper around it that just returns the string.