elder_scrolling/README.md

# 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.