A simple frontend for the SWAPI (the Star Wars API).
The app can be used to search for characters in the Star Wars universe and find out information about them.
A deployed version can be found here.
The app is written in Elm, styled with use of Furtive, tested using cypress and bundled using parceljs.
yarn install # install dependencies
yarn run dev # run app locally (default localhost:1234)
yarn run cypress:open # open cypress test GUI
yarn run cypress # run cypress tests from command line
N.B. cypress tests are run against locally running app so will need yarn run dev to have been run.
Given the relatively limited time I am able to spend on this app I am prioritising what are in my opinion good practices over large feature set.
The app should handle:
- Error statuses from api
- Slow load of api / slower internet connections
I am from a predominantly backend background with a strong emphasis on TDD. I wanted to experiment with Elm/cypress combination as it seems to tackle some of the problems I see on other javascript based stacks.
In particular I have seen a lot of low value "change detector" implementation tests that I think come from uncertainty about javascript features. Have we destructured the input correctly? Are all the keys correct in the output object? I am hoping the type system in Elm moves these kind of tests to the compiler, allowing testing to be more about features of the app.
This fits nicely with the approach taken by cypress, writing tests describing the interaction a user has rather than the underlying implementation. With selenium/webdriver I have seen this fall down due to the slow speed and flakiness of the tests but it looks like there are a number of features in cypress to address this.
Some considerations going forward if this were a production project:
- Accessibility
- Localisation
- Security concerns e.g. Content Security Policy, headers