Making test tasks is always very confusing to me because I'm not really sure what exactly each reviewer in each case will watch into, what is more important for him. Is it a codestyle (which i always can change according to team conventions) or is it more about how i resolve some non-standard issues (which can be not represented in some cases), or if we are talking about project architecture - is it more interesting for reviewer to see the project which is built supposing it is something that will grow bigger or otherwise reviewer don't want to see exaggerated implementation of a simple task and will consider it as a minus for me. And if it's the first way - when should i stop, cause i can't use YAGNI principle here since it's not a real project and i can't define when to stop relying on what i really need, since i don't know what i need here.
Also wanted to warn you that lots of decisions were made here in rush to finish this project asap because the longer i'm making it the faster i'm running out of money since i already left my previous job and completely focused on joining Tendermint, so i hope you won't consider some excessive style rules or lack of some functionality which were not explicitly stated as required, as something that will dramatically affect on your final impression from the task implementation.
Anyway i really tried my best so if you would have any questions and doubts about implementation of anything here - i'm open to answer and explain anything!
P.S. I mocked all "basic tokens" so please feel free to use pairs with ETH + any basic token. I could of course add more mocks for other tokens but I have been told it's not really necessary. And yeah, in real app i would use websockets or repeated requests for updating all the information, but it's overcomplicated for a simple task and too hard to mock up so i haven't implemented it here.
yarn install
yarn serve
yarn build
yarn lint