## Description I moved each component except for the nav component, which is used in each view, into a folder named after the view in which the component is used. ## Reference to official issue There is no official issue related to this. ## Motivation and Context The components folder already has a lot of files in it. It would be good to establish some patterns for organizing frontend files early on. ## How Has This Been Tested? I ran `docker-compose -f local.yml up` and saw that the frontend interface still worked the way it was working before. ## CLA - [X] I have signed the CLA; if other committers are in the commit history, they have signed the CLA as well

@louisgv I was thinking about it, but no I am not currently working on this.

Where can we find some sample DICOM image data? I didn't see anything in the developer documentation. Should we just pull from the internet for now?

For production and testing for production locally, we will want to serve the frontend app index page located at `interface/frontend/templates/index.html` for requests to `'/'` on the Django server. ## Expected Behavior Visiting `'/'` at `localhost:8000` renders the compiled frontend app. ## Current Behavior At the moment, visiting `'/'` at `localhost:8000` yields a `404`. ## Possible Solution Add a route which serves the compiled frontend app. ## Steps to Reproduce 1. `docker-compose -f local.yml up` 2. Visit `localhost:8000` in browser <img width="944" alt="screen shot 2017-09-23 at 9 06 39 pm" src="https://user-images.githubusercontent.com/7776175/30779391-9c00934e-a0ac-11e7-932d-0fe659bd67d8.png"> ## Context (Environment) I was trying to see how the compiled app looks and noticed that the Django server is no longer serving the frontend app. To get the app ready for production, we need to know that the compiled app is working as expected. ## Possible Implementation [PR 97](https://github.com/concept-to-clinic/concept-to-clinic/pull/97) had the compiled app being served from `localhost:8000` so it may be able to be used as a reference. ## Checklist before submitting - [X] I have confirmed this using the officially supported Docker Compose setup using the `local.yml` configuration and ensured that I built the containers again and they reflect the most recent version of the project at the `HEAD` commit on the `master` branch - [X] I have searched through the other currently open issues and am confident this is not a duplicate of an existing bug - [X] I provided a **minimal code snippet** or list of steps that reproduces the bug. - [X] I provided **screenshots** where appropriate - [X] I filled out all the relevant sections of this template

FYI, I added a couple small improvements to this PR since this was last reviewed.

Yeah, I was just pointing out that the API endpoints for some of these frontend actions aren't in place yet. I don't think adding those endpoints is within the scope of this issue though.

## Description This PR takes the existing views built by @WGierke, including his unmerged frontend work on [#34 Select Lung Orientation](https://github.com/concept-to-clinic/concept-to-clinic/pull/101), and turns them into components of the main Vue app. VueRouter was set up to handle page navigation, and jQuery and Bootstrap.js were removed. Axios, an alternative to jQuery's Ajax, was added because it makes it easier to set default request options. I also made a few backend changes because I was getting errors when trying to create some test data through the Django REST interface. ## Reference to official issue [Port existing pages to frontend Vue project #110](https://github.com/concept-to-clinic/concept-to-clinic/issues/110) ## Motivation and Context This change will allow us to serve all templates from the main Vue app, and sets up basic routing and frontend file organization patterns that will give the app some structure moving forward. ## How Has This Been Tested? This has been tested by running `docker-compose -f local.yml build` to install new dependencies, followed by `docker-compose -f local.yml up`, and navigating to all the links in the navigation. I created test data using the Django REST interface to verify that actions like toggling elements that can be opened and closed and making backend requests works as expected. ## Screenshots (if appropriate): <img width="998" alt="screen shot 2017-09-18 at 8 27 20 pm" src="https://user-images.githubusercontent.com/7776175/30573252-0389e8ea-9cb0-11e7-9043-34835acd6ad4.png"> <img width="996" alt="screen shot 2017-09-18 at 8 27 58 pm" src="https://user-images.githubusercontent.com/7776175/30573253-038babee-9cb0-11e7-8cdc-c0646d30c23a.png"> <img width="997" alt="screen shot 2017-09-18 at 8 28 20 pm" src="https://user-images.githubusercontent.com/7776175/30573251-0388811c-9cb0-11e7-9c64-a5bb6fb67593.png"> ## CLA - [X] I have signed the CLA; if other committers are in the commit history, they have signed the CLA as well

@WGierke and @isms, I would like to propose removing jQuery (and bootstrap.js) from the project altogether. Vue alone is able to handle all the front-end reactivity that bootstrap does in their JS-supported elements with less code. Also, jQuery's ajax isn't well suited to setting default data params -- see the convoluted solutions described [here](https://groups.google.com/forum/#!topic/jquery-dev/OBcEfgvTJ9I). Instead we could use [axios](https://github.com/mzabriskie/axios#request-config), which makes it easy to set base configuration options including options for `xsrfTokens` and `xsrfHeaders`. Or we could use Vue's built in http functionality as @isms suggested above. Anyway, I am close to done with a PR that should address #110, and I've integrated/ported the frontend code from this PR for which I'll be sure to credit @WGierke. I hope to have that ready for review soon, but I wanted to give my opinion regarding using jQuery after reading through the most recent comments on this PR.

Before the base Vue app was merged ([PR 97](https://github.com/concept-to-clinic/concept-to-clinic/pull/97)), several frontend pages were developed and merged. These pages were being served from Django. It was later decided that all pages should be served from the single instance of the Vue app (see [here](https://github.com/concept-to-clinic/concept-to-clinic/issues/106#issuecomment-328642670)). As a result, these existing pages need to be ported over to the Vue app. ## Expected Behavior The base Vue app in `interface/frontend/src/main.js` should serve all existing page templates using `VueRouter`. Clicking on a link should load the expected page template. ## Current Behavior At the moment, only the navigation is displayed when loading the home route from Django and clicking on links in the navigation does not render any of the existing page templates. ## Possible Solution The code from PR's [73](https://github.com/concept-to-clinic/concept-to-clinic/pull/73), [84](https://github.com/concept-to-clinic/concept-to-clinic/pull/84), [85](https://github.com/concept-to-clinic/concept-to-clinic/pull/85), [88](https://github.com/concept-to-clinic/concept-to-clinic/pull/88), [92](https://github.com/concept-to-clinic/concept-to-clinic/pull/92), and [93](https://github.com/concept-to-clinic/concept-to-clinic/pull/93) will need to be modified to use ES6 syntax and served from the Vue app using `VueRouter`. ## Steps to Reproduce 1. Fix the issue with the broken asset link as described in [issue 106](https://github.com/concept-to-clinic/concept-to-clinic/issues/106) 2. `cd interface/frontend && npm install && npm run build` 3. `cd ../..` 4. `docker-compose -f local.yml up` 5. Visit `localhost:8000` -- only the navigation appears ## Context (Environment) Until the existing work is integrated into the base Vue app, it will be difficult to develop the remaining features which need to be built on top of these existing templates. ## Detailed Description I am proposing to set up `VueRouter` and add all the necessary frontend routes to serve the page templates that have already been developed. These existing Vue components will also need to be updated to ES6 syntax in order for the frontend build process to succeed. ## Checklist before submitting - [X] I have confirmed this using the officially supported Docker Compose setup using the `local.py` configuration and ensured that I built the containers again and they reflect the most recent version of the project at the `HEAD` commit on the `master` branch - [X] I have searched through the other currently open issues and am confident this is not a duplicate of an existing bug - [X] I provided a **minimal code snippet** or list of steps that reproduces the bug. - [X] I provided **screenshots** where appropriate - [X] I filled out all the relevant sections of this template

@WGierke, the issue with no content appearing is not your fault. When I started working on the frontend build process, I made a recommendation to serve all pages (other than the initial application load) through Vue, which @isms seemed to agree with [here](https://github.com/concept-to-clinic/concept-to-clinic/issues/6#issuecomment-325644418). In the meantime, you were completing issues using a different scheme in which the base views for each page were rendered from Django. These pages and content that you were working on will need to be ported over to the SPA scheme that I set up in [PR 97](https://github.com/concept-to-clinic/concept-to-clinic/pull/97) or, if the project supervisors think that we should use the scheme that you have been developing with, then we will need to update the frontend build process.

@lamby - rebased against master again

This PR adds the ability to compile the frontend into static files that can be served by the django backend. It also modifies the Dockerfile to install the frontend project's npm dependencies. ## Description I began with the vue-django webpack template and updated it to use Vue 2 and Webpack 2. The existing views built by @WGierke's and served by django were integrated into the Vue app in order to be able to leverage the VueRouter for navigating between pages. Rendering one view which initializes a SPA will make page transitions faster than asking the backend for new templates each time a link is clicked and simplifies development because all view rendering and route handling happens in one place. I had to modify the base image for the dev Dockerfile because I was having difficulty installing node and npm with the Python 3.6 base image. I chose the latest Ubuntu image, but Debian and others would probably work too. I am not sure if there is a need to install the npm dependencies in docker however, because the `npm run build` command which compiles the production assets is run by devs outside of docker anyway, right? Or was the intention to also have Docker compile the production assets if they didn't exist in the dev's repo? If not, I can get rid of these changes to the Dockerfile. Regarding needing to have 2 servers for frontend development, this would be the case if we wanted to have hot-reloading, but you could also run `npm run build` and serve the compiled assets with only the django backend server running. I do think we should invest the time to get the frontend dev server with hot-reloading working since this will greatly improve the frontend development process, but I was having trouble getting it working after updating Vue and Webpack and wanted to get this PR out. ## Reference to official issue [Set up a basic npm vue/webpack setup #6](https://github.com/concept-to-clinic/concept-to-clinic/issues/6) ## Motivation and Context We need a way to compile the frontend app and serve it from django. ## How Has This Been Tested? I ran `docker-compose -f local.yml build` to ensure that the project's npm dependencies get installed. I ran `npm install` and `npm run build` from the frontend directory, then `docker-compose -f local.yml up`, and navigated to localhost:8000 and saw this: <img width="1316" alt="screen shot 2017-09-06 at 10 51 49 pm" src="https://user-images.githubusercontent.com/7776175/30146566-0a8b630c-9356-11e7-8065-e2f8bc2c87c8.png"> ## CLA - [ X] I have signed the CLA; if other committers are in the commit history, they have signed the CLA as well

I've been working on this issue, and I have a few questions. 1) I see that in the "Project Structure" section of the docs there is an asset folder that is outside of the backend and frontend directories. May I propose hosting the built assets for production inside an asset folder inside the frontend folder? By putting the assets outside the frontend project, at least one of webpack's handy features won't work. If we want to append a hash to the compiled frontend assets, so that browsers know when the production assets have been changed and need to be re-fetched, then we probably want to delete old compiled assets so they don't pile up. In order to use webpack's `clean-webpack-plugin`, the assets folder cannot be outside of the frontend project root. See screenshot below. <img width="989" alt="screenshot" src="https://user-images.githubusercontent.com/7776175/29801623-e11c79b8-8c2d-11e7-8f5a-e05ec2785eaa.png"> 2) I see that there is an open PR for a base frontend template done in Django ([#9 Layout base Django template to match wireframes](https://github.com/concept-to-clinic/concept-to-clinic/pull/73)). I think all of the frontend interface should be compiled through Vue in order to leverage the speed/reactivity of a SPA in every part of the application. It also adds complexity when there are two entirely different places where views are rendered. Can we avoid merging the base Django layout, and is it ok if I incorporate WGierke's work on the base layout into the base Vue app?