Interview Task - ThinkEngineer/WebAppTask GitHub Wiki
Welcome to the Think Engineer Interview Task.
What already exists?
We have created this basic App using feathersJS for the API, and Vuetify for the front end. The backend is very simple and is a default Feathers application with local authentication strategy, which uses the users service. A user can have an email address and a password. When the user logs in they are issues a JWT. For data storage Nedb is used, which creates a local file which acts as a database.
From within the /server folder you can run the Feathers application with npm run dev. This will run it with nodemon so your changes take immediate effect.
This will expose and API on http://localhost:3030
Two endpoints are available, /users and /authentication.
/users is used to find, get, create, update, patch and remove users.
/authenticate is used to sign in with existing user credentials, and get a JWT.
The Vuetify application uses FeathersVuex to integrate with the backend. There are 3 views currently; login, register and dashboard, as pictured below.
The login page requires your email address and password to be provided, and if they are correct you will be resirected to the dashboard.
If you do not yet have an account you can signup with one on the register page.
The dashboard is only accessible if you are logged in with valid credentials. This page has a logout button.
You can run the frontend from within the client folder, using npm run serve.
It is then accessible at http://localhost:8080
Your Tasks
There are a number of tasks that I want you to complete during the interview, however you are welcome to try and do them beforehand for practise, but I will still want you to do them live during the interview.
Task 1 - Sensors Service
Use the Feathers CLI to generate a new service called 'sensors'. This should require authentication to be used.
These resources will be useful to install feathers CLI, and generate the 'Sensors' service on the command line.
To create a sensor, the following information is required:
- Name - name should be unique
- Location - this should store latitude and longitude
- status - This can be set to one of two values; 'active' or 'inactive'
When created, the user creating the sensor should be set as teh owner of the device using the Feathers hook, associateCurrentUser.
Write unit tests to prove ensure that when the following:
-
When {name: 'testSensor', Location: '[51.4543, 0.9781]', status: 'inactive'} is posted, a sensor is successfully created and is returned as {name: 'testSensor', Location: '[51.4543, 0.9781]', status: 'inactive', ownerId: 'aUserId'}
-
When {} is posted, no record is created and a helpful message is provided, e.g. 'Name, Location and Status are required fields'.
Task 2 - Create Sensor from the Dashboard
Within the client project, create a new component that is a nicely presented form (similar looking to the registration form). The form should allow the user the enter the Sensor Name with a text field, select the Status with a v-switch, and Location, ideally with a map based location selector, but if not then text boxes will do.
Validate the form with :rules to ensure that the Sensor Name is not empty. If the form is not valid.
There should be a create button that is disabled if the form is not valid, and is enabled when the form becomes valid. Pressing enter within any text field or clicking the 'Create Sensor' button should call a 'createSensor' method, which uses a Sensor model in the Store to create the sensor on the backend.
This new component should then be added to the Dashboard. By default it should not be shown, but using a Floating Action Button that is in the bottom right hand corner of the Dashboard, it should be displayed.
After trying to create a Sensor, an Alert should be displayed informing the user if the action succeeded or failed.
Task 3 - Show the users sensors
Finally, the Dashboard should be used to show the users sensors. Each Sensor should be a nicely formatted card that shows the sensor name, the status using a v-switch and the location, ideally on a map, but a label will be OK.
Each Sensor that is created by the currently logged in user should be displayed in its own card, and there should be at most 4 cards per row. Formatting of the cards on the Dashboard should be done using the Grid System
The Sensors shown on the Dashboard should be a realtime representation of the sensors in the database. If you open two tabs and go to the dashboard on both pages, then when you create a new Sensor on one tab, it should be displayed on both. Reactive Store
Below are some wireframes that may be helpful.