Move to Vue 3

.eslintrc.js

@@ -4,7 +4,7 @@ module.exports = {
     ecmaVersion: 2020
   },
   extends: [
-    'plugin:vue/recommended',
+    'plugin:vue/vue3-recommended',
     '@vue/airbnb'
   ],
   env: {
@@ -41,6 +41,7 @@ module.exports = {
       minProperties: 0,
       consistent: true
     }],
+    'object-property-newline': 'off',
     'operator-linebreak': ['error', 'after', {
       overrides: { '?': 'before', ':': 'before' }
     }],

.gitignore

@@ -20,6 +20,7 @@ node_modules
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+pnpm-debug.log*
 
 # Editor directories and files
 .idea

CONTRIBUTING.md

@@ -115,9 +115,11 @@ Most components are named according to the combination of a resource and an acti
 * `Edit`. A component used to update an existing resource of a particular type.
 * `Delete`. A modal used to delete an existing resource of a particular type.
 
-### Vue Mixins
+### Reusability: Mixins and the Composition API
 
-Each component may use one or more mixins. Each file in [`/src/mixins/`](/src/mixins/) exports a mixin factory for a single type of mixin. (We use factories so that the component can pass in options for the mixin. We don't use this pattern much anymore though, so we will likely change this when we move to Vue 3.)
+Components can share reusable code. They can do so using either mixins or the Composition API. Several pieces of reusable code are available as both a mixin and a composable: see [`/src/reusables/`](/src/reusables/). A component using the Options API should use the mixin, while a component using the Composition API should use the composable. Some pieces of reusable code are currently only available as a mixin: see [`/src/mixins/`](/src/mixins/).
+
+ODK Central Frontend recently moved from Vue 2 and Vue 3, and we are still establishing patterns in this area. Currently, the vast majority of components use the Options API, but that may change: we could start preferring the Composition API for new components. Alternatively, we may decide to leave the Composition API for specialized cases. How we end up using the Composition API will influence how we approach mixins and composables in the future.
 
 ### Router
 
@@ -127,9 +129,9 @@ The initial navigation is asynchronous, in part because it tries to restore the
 
 If the user navigates to a location to which the `validateData` meta field forbids access, the user will be redirected to either `/` (if they are logged in) or `/login` (if they are not logged in). That means that unless the user is already at `/` or `/login`, navigating to a different location will always result in some confirmed navigation: either the first navigation will be confirmed, or the redirect will be confirmed. In other words, the user is guaranteed to navigate elsewhere: the route will change. Nonetheless, `router.push()` and `router.replace()` may return a rejected promise, if the first navigation is aborted. If that is a possibility, call `catch()` on the promise.
 
-Before the user's session expires, the user will be automatically redirected to `/login`. Further, in general, the user is permitted to change the route at any time. That means that components should be prepared to be destroyed at any point. For example, if a component starts asynchronous work, it should probably check when that work completes whether the route has changed.
+Before the user's session expires, the user will be automatically redirected to `/login`. Further, in general, the user is permitted to change the route at any time. That means that components should be prepared to be unmounted at any point. For example, if a component starts asynchronous work, it should probably check when that work completes whether the route has changed.
 
-We store router state in the Vuex store (see [`/src/store/modules/router.js`](/src/store/modules/router.js)). Some router-related utilities are defined in [`/src/util/router.js`](/src/util/router.js), and components can access router-related methods by using the `routes` mixin ([`/src/mixins/routes.js`](/src/mixins/routes.js)).
+We store router state in the Vuex store (see [`/src/store/modules/router.js`](/src/store/modules/router.js)). Some router-related utilities are defined in [`/src/util/router.js`](/src/util/router.js), and components can access router-related methods by using `usePaths()` or `mixinPaths` ([`/src/reusables/paths.js`](/src/reusables/paths.js)).
 
 The router is responsible for updating the document title (text in the browser tab and history) when navigating to a new route. It uses the `parts()` function in a route record's `meta.title` field. Much like with `validateData`, it may not have all the information it needs when first changing the route (e.g. navigating to a new Project page), so it watches for changes to the Vuex store (the key to watch is defined in `meta.title.key`) and then updates the page title again (e.g. using a Project's name after the project info has been fetched from the backend.)
 
@@ -231,7 +233,7 @@ To add a new locale to ODK Central Frontend:
 1. Add the locale to Transifex.
 2. Add the locale to `locales` in [`/src/i18n.js`](/src/i18n.js) and [`/bin/util/transifex.js`](/bin/util/transifex.js).
 3. If the locale pluralizes differently from the default, specify its pluralization rules in `/src/i18n.js`.
-4. Check that there is a flatpickr config for the locale. If there isn't one, create a GitHub issue in this repository or contact us on Slack.
+4. Import the flatpickr config for the locale in [`DateRangePicker`](/src/components/date-range-picker.vue).
 5. Consider spot-checking the translations. In particular, check that messages used in component interpolation have been translated correctly.
 
 Note that right now, the router will use the user's preferred language to load the locale, but it will only use the first subtag of the language. If/when we add a locale with multiple subtags, we will need to update the router.
@@ -306,7 +308,7 @@ You can use `mockHttp().testStandardButton()` to test some of these things for a
 
 To run tests, type `npm run test`. This will run all `*.spec.js` files in [`/test/`](/test/).
 
-The core of our tests is the tests of the components and the tests of the router, which together implement most of the business logic. We also have unit tests of mixins, the Vuex store, utility functions, and so on. The directory structure of `/test/` largely mirrors that of `/src/`. For example, each test file in `/test/components/` corresponds to a component in `/src/components/`; each test file in `/test/mixins/` corresponds to a mixin in `/src/mixins/`. The exception is that the files in `/test/util/` do not test the files in `/src/util/`, but rather are test utility functions. The files in `/src/util/` are tested by those in `/test/unit/`.
+The core of our tests is the tests of the components and the tests of the router, which together implement most of the business logic. We also have unit tests of composables/mixins, the Vuex store, utility functions, and so on. The directory structure of `/test/` largely mirrors that of `/src/`. For example, each test file in `/test/components/` corresponds to a component in `/src/components/`; each test file in `/test/reusables/` corresponds to a file in `/src/reusables/`. The exception is that the files in `/test/util/` do not test the files in `/src/util/`, but rather are test utility functions. The files in `/src/util/` are tested by those in `/test/unit/`.
 
 If you add code outside a `.vue` file (for example, a utility function), and it is easy to test in isolation, consider writing unit tests to verify the code. If a function's input is very easy to directly construct or mock, for example, it is likely a good candidate for unit testing. On the other hand, when writing code that is more closely related to other code, it may work best to test the functionality in a component test or a test of the router.
 
@@ -323,7 +325,7 @@ Our tests use a number of external packages:
 
 We extend Should.js assertions in [`/test/assertions.js`](/test/assertions.js).
 
-[Vue Test Utils](https://vue-test-utils.vuejs.org/) renders Vue components for testing, allowing you to test that a component renders and behaves as expected. We have built some functionality on top of Vue Test Utils, in particular [`mount()`](/test/util/lifecycle.js). We define components used only for testing in [`/test/util/components/`](/test/util/components/).
+[Vue Test Utils](https://next.vue-test-utils.vuejs.org/) renders Vue components for testing, allowing you to test that a component renders and behaves as expected. We have built some functionality on top of Vue Test Utils, in particular [`mount()`](/test/util/lifecycle.js). We define components used only for testing in [`/test/util/components/`](/test/util/components/).
 
 Many tests involve sending a request. You can mock a series of request-response cycles by using `load()` or `mockHttp()`, defined in [`/test/util/http.js`](/test/util/http.js). You can use these to implement common tests, for example, testing some standard button things: see [`/test/util/http/common.js`](/test/util/http/common.js).