Caused trouble because of route collisions, so the integration was done now.
Required distinguishing Maker and Taker on the cfd level, which comes in handy anyway.
We distinguish by order origin, but still map to a `Role` enum (`Taker` / `Maker`) for readability.
To avoid duplication the `Role` from contract setup was moved into the model and used throughout.
All display related decisions are taken in the UI, but on top of the UI's model.
For this purpose we introduce classes for `CfdState` and `Position` so we can add the relevant mapping functions to these classes.
To achieve the mapping from daemon sse even to the `Cfd` / `Order` interface (that now contain classes instead of just primitives) we extend the sse hook to accept a mapping function.
We define this mapping function for `Cfd` and `Order`, because those contain classes, for all others we just use the default mapping.
Actions are dynamically rendered based on the state.
The daemon decides on the action name.
A single post endpoint handles all actions.
The UI maps the actions to icons.
Co-authored-by: Thomas Eizinger <thomas@coblox.tech>
We can create a grid that has two columns:
- The first one is set to `max-content`.
- The second one is set to `auto`.
This will make the first columns as wide as the widest row and the
second column will take up the remainder of the space given by the
parent container.
When sorting the triangle appears next to the header text - that is expected and standard behaviour.
The span was always rendered (also with no sorting), and message up the alignment of the text.
Additionally add a text-align right for fixing the `State` header, that was somewhat floating around.
The Grid was restrictive and caused problems overlapping things.
We can achieve better layouting with flex components (for now mostly HStack and VStack flexes).
We can eventually also add space bounds to the flexes for more layourting (i.e. graph should take 70% on right...), but for now I kept it rather simple.
I experimented with Grids for the tiles where we group information (i.e. Buy, Order) but it did not look good, so I amd using flexes with fixed label width for better looks.
Bundling the frontend does not necessarily require type checking,
nor should type checking imply bundling.
TSC is also fairly slow. Separate the two and invoke tsc separately in
CI.
The only thing that has to stay in the root is the `index.html` file,
otherwise the dev server doesn't pick it up.
Also make sure our frontend tests actually run and pass in CI.
Vite deletes the `dist` directory on re-builds. That will also delete
the gitignore which makes the generated files show up in Git.
We need those directories to exist otherwise `rust-embed` fails.
Use a build-script to create them when we compile the daemons.
Note: we need to check-in `frontend/dist` directories as otherwise the build will fail.
If you want to embed the files into the binaries you will need to build them first (`yarn run build`).
- 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.
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.
The buy margin is calculated from `initial_price`, `quantity` and `leverage`.
The sell margin is calculated from `initial_price` and `quantity` (no leverage trading for the seller at the moment).
Includes several refactors:
- Separate API interface for `Cfd` and `CfdOffer` when mapping `toSseEvent`. This allows internal modelling to be different than the exposed API.
- Remove the profit calculation internally, it is only relevant on the UI feed API level.
- Move code that is specific to taker/maker http API from `model` to the respective `routes` module.
- Some simplification of the calculation model of `Usd` (could be further improved by deriving calculation traits)
- Introduces `OfferOrigin` used to save the offer's origin as `mine` and `others` in the database. This is used to properly derive the CFD position from the offer.
Daniel Karzel
Mariusz Klochowicz
Thomas Eizinger
Philipp Hoenisch