An Elm application that retrieves survey result information from a JSON API, and displays the results.
I also wrote implementations of the companion back-end developer test to this front-end test in Elixir and Ruby, which can be found at the following:
- https://github.com/paulfioravanti/survey_tool_elixir
- https://github.com/paulfioravanti/survey_tool_ruby
My review of the coding tests can be found in the following blog post:
git clone https://github.com/paulfioravanti/survey_tool_elm.git
cd survey_tool_elm
The back end is an Elixir app that uses Plug.Cowboy to serve the JSON files expected by the front end.
- Elixir 1.15.7 (asdf-elixir pre-compiled version: 1.15.7-otp-26)
- Erlang 26.1.2
cd back_end
mix deps.get
mix run --no-halt
Now, you should be able to open the following links and get the appropriate JSON response:
- http://localhost:4000/survey_results
- http://localhost:4000/survey_results/1
- http://localhost:4000/survey_results/2
Other addresses should return an error JSON object.
For easy reading of JSON objects in a browser, I recommend the JSON Formatter extension for Google Chrome.
The back end server has a small suite of tests, written with ExUnit, that can be run with:
mix test
mix test.watch
was used during development, so that can also be used here
to continuously run tests on file changes.
The front end is an Elm application that displays the survey result data. It uses Tachyons for functional CSS styling and responsive layouts for mobile and desktop screens, making this front/back end combo one "P" short of the PETE stack (I figured making the back end a Phoenix application would have been overkill).
I used the following global npm packages during development, so I recommend installing them to be able to run all application and testing commands:
Install:
npm install -g elm-test create-elm-app elm-verify-examples elm-coverage elm-analyse
In order to get mix test.watch
-like functionality with Elm, I used:
They can both be installed with Homebrew:
brew install just watchexec
cd front_end
npm install
cp .env.example .env
In development, if you want to serve up the back end JSON application from a
location other than http://localhost:4000, then you can
configure that in the .env
file.
NODE_OPTIONS=--openssl-legacy-provider elm-app start
The
--openssl-legacy-provider
option is needed until this issue gets addressed.
Now, you should be able to use the app at the following address:
(Make sure you also have the back end server running to actually see the survey results).
Straight tests:
elm-test
Verified examples (doctests):
elm-verify-examples
Run tests and generate code coverage report.
Coverage is currently stuck at 99% because there is no way to generate a
Navigation.Key
forBrowser.application
apps in a test environment. Hopefully, that will be fixed one day, but the issue to follow is here.
elm-coverage
open .coverage/coverage.html
Run Elm Analyse confirm best practices are being adhered to:
elm-analyse
Note: it may take a while for the elm-css
library to be loaded the first
time this is run, so give it potentially about 10 minutes.
If you're using this app in development, you could do the following:
Use just
and watchexec
to run both elm-verify-examples
and elm-test
when any src
code is modified:
watchexec --watch src --clear=reset just test
Use just
and watchexec
to run both elm-verify-examples
and elm-coverage
(which runs elm-test
) when any tests are modified. The src
directory is not
included here because elm-coverage
ends up touching every src
file during
its instrumentation phase, leading to infinite loops:
watchexec --watch tests --ignore tests/elm-package.json --clear=reset just coverage
If you are a Tmuxinator user, you can find my config for this project here.
This repository contains a small number of static JSON files, which represent the responses from an HTTP API that offers access to a database of survey results.
Your task is to build a web front end that displays the data supplied by this API. You must process the survey data and display the results in a clear, usable interface.
We suggest you start by setting up an HTTP server that will serve up these JSON files upon request. This may be the same server that serves your web application to consume the API, but make sure to design your application in such a way that you could easily point it to an arbitrary base URL for the API, somewhere else on the Internet.
One you’ve got the API available, use whatever client-side libraries or frameworks you like to build the application that consumes it.
(Tip: If your application will access the API directly from the browser, using the same server for both your application and the API it consumes will save you having to deal with cross-origin requests. Of course, if you enjoy that sort of thing, feel free to go for it!)
index.json
is returned when you send a GET request for the root URL. It returns a list of the surveys that are stored in the database, and high-level statistics for each. For each survey, a URL is included that points to one of the other JSON files.
The remaining JSON files each provide full response data for one of these surveys. Each survey is broken into one or more themes, each theme contains one or more questions and each question contains a list of responses. A response represents an individual user ("respondent_id"
) answering an individual question ("question_id"
). The content of each response represents an agreement rating on a scale of "1"
(strongly disagree) to "5"
(strongly agree). If you wished, you could obtain all of the responses for a single user by consulting all of the responses with that user’s "respondent_id"
.
Your application should include:
- a page that lists all of the surveys and allows the user to choose one to view its results;
- a page that displays an individual survey’s results, including:
- participation rate as a percentage
- the average rating (from 1 to 5) for each question
Responses with an empty rating should be considered non-responses (questions skipped by the survey respondent). These responses should be excluded when calculating the average.
You can deliver a set of static HTML pages that consume the API data with JavaScript, but keep in mind that we need to be able to read your code, so if you’re compiling your JavaScript in any way, please include your source code too. Alternatively, if you want to build an application that runs on its own web server, that’s okay too.
- Be creative in considering the right way to display the results.
- Feel free to use frameworks and libraries, but keep in mind that we are looking for something that demonstrates that you can write good front-end code, not just wire up a framework.
- Static JSON files load pretty quickly, but not all web APIs are so performant. Consider how your application will behave if the API is slow.
- Include a README file with clear build instructions that we can follow.
- Include in your README any other details you would like to share, such as tradeoffs you chose to make, what areas of the problem you chose to focus on and the reasons for your design decisions.
- We like tests.
Beyond meeting the minimum requirements above, it’s up to you where you want to focus. We don’t expect a fully-finished, production-quality web application; rather, we’re happy for you to focus on whatever areas you feel best showcase your skills.
Assuming you use Git to track changes to your code, when you’re ready to submit your solution, please use git bundle
to package up a copy of your repository (with complete commit history) as a single file and send it to us as an email attachment.
git bundle create front-end-coding-test.bundle master
We're looking forward to your innovative solutions!