104 lines
4.5 KiB
Markdown
104 lines
4.5 KiB
Markdown
# Elder Scroll Display
|
|
|
|
## Synopsis
|
|
|
|
The Highspot Coding Challenge. The premise is to display a deck-builder
|
|
card catalog (such as Magic The Gathering, although in this case it's
|
|
Elder Scrolls) made available via a RESTful API. The requirements as
|
|
set out in the Code Challenge are:
|
|
|
|
### Requirements Checklist
|
|
|
|
- ✓ Show results in a card grid format with the image prominently displayed.
|
|
- ✓ Each card displays: Image, Name, Text, Set Name, and Type. Additional fields are optional.
|
|
- ✓ Display a loading indicator when communicating with the API.
|
|
- ✓ Use a responsive design that accommod_es, at minimum, desktop and mobile.
|
|
- ✓ Initially, fetch and display the first 20 results returned by the API.
|
|
- ✓ As the user scrolls down the page, load and append additional cards using "infinite scroll."
|
|
- ✓ Retrieve additional pages of results as-needed but do not load more than 20 cards with
|
|
each request.
|
|
- Allow the user to search for cards by Name.
|
|
- ✓ Use modern open-source web technologies to implement your solution (React, Backbone,
|
|
Angular, Vue, Underscore, etc.).
|
|
- Provide instructions for prerequisites, installation, and application setup and build in a
|
|
README file.
|
|
|
|
### Evaluation Criteria
|
|
|
|
- Are all stated requirements met?
|
|
- Does the application successfully build and run?
|
|
- Is the code well-organized and easy to understand?
|
|
- Does the code reflect contemporary web development techniques?
|
|
- Are functions and variables clearly named to express their purpose?
|
|
- Was the solution visually appealing?
|
|
- Were any scope decisions, TODO items, and known issues called out in
|
|
code comments or the README file?
|
|
|
|
### Available Resources
|
|
|
|
- Endpoint: https://api.elderscrollslegends.io/v1/cards
|
|
- Documentation: https://docs.elderscrollslegends.io/,
|
|
https://docs.elderscrollslegends.io/#api_v1cards_list
|
|
|
|
NOTE: The Elder Scrolls Legends API is a free, third-party service built
|
|
by an independent developer; it is not affiliated with Highspot, or with
|
|
the intellectual property owners of Elder Scrolls Legends. Please help
|
|
us use it responsibly.
|
|
|
|
## Initial impressions
|
|
|
|
This is a single-page application. The 'search' is more of a filter,
|
|
sending the `?name=<param>` to the `/cards` API endpoint. To meet the
|
|
requirements of the application, the `pageSize=20` argument must be
|
|
passed to the endpoint.
|
|
|
|
Startup seems to be relatively straightforward, and there won't be
|
|
anything fancy here: A flexbox will probably do just fine, as will a
|
|
progressive fill. I'm inclined to _not_ use MaterialUI here; it's
|
|
probably overkill. Just an application, with some nice CSS and a decent
|
|
cache.
|
|
|
|
For the search feature, we'll want to go with whatever the API offers,
|
|
but when clearing the search, let's go for a fast reload with no data
|
|
requirements. That's provide some speed when going back to the basics.
|
|
I won't be using the ServiceWorker, as I don't feel confident enough in
|
|
my familiarity with it to make it matter.
|
|
|
|
Also, because I'm a *nerd*, I can't start without first picking out a
|
|
theme: white on black, with a paper texture from my design library
|
|
desaturated, darkened, and rendered a seamless tile, using the Google
|
|
'Marcellus' font, which kinda sorta looks Tolkeinesque.
|
|
|
|
## Progress
|
|
|
|
It looks pretty.
|
|
|
|
![ElderScrolling](./ElderScrolling.png)
|
|
|
|
Criticism: "Cards" is doing too much, and not enough. It would make
|
|
more sense to have a moving window, showing no more than what it would
|
|
take to show the user what is expected at that moment, with the ability
|
|
to load high and low, keeping only what the user is _looking at_ in the
|
|
DOM tree.
|
|
|
|
Proposal: Cards needs a CardCollection proxy object, which the Cards view
|
|
object (personal convention: TSX files are named for what they show,
|
|
semantically; TS files may be suffixed with "Model" or "Collection",
|
|
a'la Backbone, to seperate them from the views, if needed; "Model"
|
|
objects are very rarely needed) taps it as the user moves up and down;
|
|
the IntersectionObserver tool would be pretty good for this; and if the
|
|
proxy actually _cached_ the fields it had already seen, it wouldn't be
|
|
slow at all.
|
|
|
|
The proxy object could also support the search feature by keeping two
|
|
collections: one of the "whole" set, and one of the "last search" set;
|
|
the proxy could swap between them as needed.
|
|
|
|
Enhancement: Well, it could use a "zoom" feature with a nice overlay.
|
|
It might even be lovely to have a second page with all the things I
|
|
haven't shown, like attributes, subtype, rarity (not, not the pony),
|
|
or keywords.
|
|
|
|
Enhancement: It is possible to search based on set, attributes, and so
|
|
forth, so a sidebar with those as filters would also be kinda cool.
|