Note that the linter acts on Vue components in both `.js` and `.vue`
files.
To keep the changes minimal and targeted, for now the linter uses a very
permissive rule-set which essentially means that the linter is mostly
disabled. As a separate change, we should fix all the lint issues and
tighten the rule-set to `plugin:vue/recommended`.
Currently Django and Vue are somewhat coupled in that the project
intermixes templating constructs from both eco-systems.
Examples of this in `projects.html` include:
- Checking if the user is a superuser to modify the Vue template.
- Using Django filters to inject the capitalized username.
This makes it somewhat hard to follow the Vue code and also makes it
more difficult to modularize the Vue components and re-use them.
As such, this change improves the separation of concerns by having the
Django template only scafold the root element for Vue and serialize any
variables that are required from the Django context to Javascript so
that Vue can access them. The rest of the templating is then moved into
a Vue single file component. This will make it easier for the developer
to understand the Vue components and make it very clear what is rendered
by Django and what is rendered by Vue.
Currently the Swiper library is referenced in the base template which
means that its CSS and JS get included and loaded on every page.
However, the Swiper functionality is only used on the landing page. This
leads to redundant requests to load the CSS and JS and may even lead to
hard to debug potential issues with clashing JS or CSS.
This change moves the Swiper JS and CSS to only be included on the
landing page.
Previously some of the Vue code relied on script tags being present in
the host application, to include dependencies such as lodash or marked.
This is not ideal for encapsulation since it means the Vue components
are not self-contained, makes testing harder, etc.
As such, this change replaces the script tag includes with ES6 imports.
Additionally, the lodash dependency (which was used only for debouncing)
is replaced in this change with the vue-debounce library which offers a
debouncing directive. This simplifies the code and avoids potential
gotchas with the this context in the debounced function.
Using a multi-stage build reduces the image size from 1.23GB to 331MB
which means that any node running doccano can now start-up faster.
Additionally, the multi-stage build means that we no longer include
development tools like node or gcc in the production image which reduces
the attack surface of the image.