- wallet feed that sends balance + current address
- display in UI (balance + address) in separate wallet component (shared for taker and maker for now)
Includes two seed files that are already funded with some testnet coins. We can share those for testing for now. If more funds are needed I'm happy to top them up.
Includes validating that the amount the other party commits to is the expected amount based on calculating the counterparty margin out of the CFD values.
Note: We could also remove the lock amount from the messages and use the calculation on both sides - that would simplify things.
Flattening the Cfd out in the internal mode has caused duplication and confusion.
This refactor puts the Order into the Cfd to make relations clearer.
Note that once we have multiple leverage the leverage and liquidation price will have to move into the Cfd because they depend on the user's choice then.
This should be trivial to do.
Achieving this is rather tricky due to the nature of our multi-page
project. We need to solve several problems:
1. We want a single npm project that produces two independent bundles.
2. We want our paths to be relative to the serving URL, that is `localhost:3000`
in development and in production, whereever the backend is hosted.
3. We have independent backends, hence requiring different `server.proxy`
configurations.
We solve (1) by using vite (already prior to this commit).
To solve (2), we simply remove all absolute URLs from the code and replace
them with absolute paths which will be relative to the serving host.
This creates a problem: Prior to this patch, we only have one devServer running
that would serve both frontends under a different sub-directory (/maker and /taker).
Even though this worked, it was impossible to create a proxy configuration that would:
- Forward API requests from `/maker` to `localhost:8001`
- Forward API requests from `/taker` to `localhost:8000`
Because in both cases, the API requests would simply start with `/api`, making
them indistinguishable from each other.
To solve this problem, we needed to serve each frontend separately. Doing so
would allow us to have dedicated proxy server configurations and forward the
requests to `/api` to the correct backend.
Unfortunately, the intuitive approach of solving this (have a `maker.html` and
`taker.html` file) does not work. With React being a client-side routing framework,
full page-reloads would be broken with this approach because they would be looking
for an `index.html` file which doesn't exist.
To work around this issue, our final solution is:
1. Use a dynamic ID to reference the desired app from within the `index.html`: `__app__`
2. Use a vite plugin to resolve this ID to the file in question: `maker.tsx` or `taker.tsx`
Fixes#6.
Extract the functionality into its own module, as the logic was exactly the same
on both sides.
I've introduced 2 new concepts:
- "own" - the caller of the function, it's either taker or maker,
depending on the OwnParams parameter,
- "other" - the other party, the opposite role.
Lucas Soriano del Pino
Daniel Karzel
Daniel Karzel
Thomas Eizinger
dependabot[bot]
Mariusz
Philipp Hoenisch
Philipp Hoenisch