Refactor container registry frontend code to ease community contribution

The container registry frontend code, due to being a proper SPA and not just a page served by Rails, it's a bit bigger and more complex than the rest.

With in mind the ability to facilitate community contributor to navigate and contribute on the code we should re-structure the code.

How

Component classification

Smart components

Smart components orchestrate multiple dumb components and connect to vuex/API they do not directly represent any UI, smart components are:

• Pages
• Complex components that encapsulate multiple components

Dumb components

They represent the UI directly, they are not connected to the store/API in any way, all the input is taken in with props and all the output is done with events. These dumb components should represent a single-piece of the UI leveraging the single responsibility principle, dumb components are:

• buttons
• list
• pagination
• modals
• any piece of the UI

Folder structure

Divide the components folder with sub-folder for each page

To avoid to have tons of constants and utility files jammed in the same file we should:

• have a folder ie: constants
• have an index.js in the folder that import any other file in the folder and exports them merged

This way we can have the constants classified per page or even more fine-grained structure if needed

Vuex store

We should divide the store in separate modules, one for each page, plus a root one containing the config (whatever we imported from the mounting dataset)

Example:

- registry/
-- explorer/
--- pages/
---- list.vue
---- details.vue
---- index.vue
--- components/
---- list_page/
----- image_list.vue
----- image_pagination.vue
---- details_page/
---- shared/
--- constants/
---- index.js
---- list_page.js
---- detail_page.js
---- index_page.js

Why

• The code and functionality is now spread across different files, enabling an easier collaboration and removing or at least reducing merge conflicts
• By adopting dumb components that are just props/events is much easier to write tests for them, and since most of the iteration is going to be done on UI pieces it will enable faster and safer iteration
• It's easy to swap in and out dumb-components, allowing us to do some a/b testing if needed and/or quickly iterate and revert
• By adhering to a stricter set of rules is much easier to grasp the intent of the code and review it