Roadmap v18

This is a multi-step roadmap rather than a single task. The first concrete piece is Step 1: add the event hub to app_shell_core with unit tests under js_tests/, wired to npm test and the CI workflow, with Shopfloor unchanged. Read the coupling table and the open points first, since the transport name and reactivity design are unresolved. Step 1 is done when the event hub unit tests pass in CI.

Roadmap: adopt app_shell_core in shopfloor_mobile_base by splitting out and improving some core concepts

Goal

Move the generic parts of the Shopfloor mobile app (import map, event hub,
fetch helper, registries, REST transport, config and app shell) into a
reusable core module, app_shell_core, so that other single page apps built
on Odoo can use them. Shopfloor keeps its domain code (scenarios, profiles,
menus, the Vue components) and consumes the core step by step.

Principles

• One step, one reviewable change. Each step moves one block, keeps the
  URLs and the behaviour, and is covered by the existing tests.
• Shopfloor keeps working at every step. Where a file moves, the old file
  becomes a thin re-export, so no caller changes in the same step.
• Easy blocks first. The blocks with no Vue dependency go first, the root
  app last.
• Each step can be reverted alone.

Coupling of each block

block	Vue coupling	Shopfloor coupling	effort
event hub	none	none	low, first
import map	none	root modules	done in Shopfloor, moves next
fetch helper	none (classic script, global window helpers)	none	low
utils registry	none	used by the colour registry (stays)	low
base registry	none	profile requirement in the route meta	medium
auth handler registry	$root in the mixin	api key handler uses $root	medium
transport	none	usage path, SERVICE-CTX-* headers, demo mock	medium
config registry	state and storage are Vue and vue2-storage	every key and its storage options	high
app shell	the whole root in main.esm.js	the whole app	high, last

Prerequisites

1. The transport name is decided (open, see below).
2. A test baseline: the UI suite green on the current code, and the demo mode
   checked by hand.

Steps

Step 1: event hub and unit tests

• Add app_shell_core with the event hub, and the unit test setup of the
  repository: Vitest, js_tests/, npm test and the CI workflow. The event
  hub comes with its unit tests.
• Nothing changes in Shopfloor yet.
• Test: the unit tests, in CI.
• Rollback: nothing depends on it yet.

Step 2: import map, and Shopfloor on the core

• Add the import map mixin (app.shell.mixin.importmap) to the core.
• Shopfloor adopts the import map and adds app_shell_core to the root
  modules of the app, so that the core's JavaScript is covered by the map.
  Without the root module, the core files fail at load time.
• Shopfloor's event hub file becomes a re-export of the core one, so no caller
  changes.
• Test: the app page loads, the import map lists the core files, and the UI
  suite (event hub, language switch, bus).
• Rollback: remove the root module and restore the event hub file.

Step 3: fetch helper

• Move fetch.js into the core, with its unit tests, and point the template
  tag to the core path.
• Test: the unit tests, and the loading indicator (fetchStart, fetchEnd)
  and the 401 logout (fetchUnauthorized) checked by hand in the app.
• Rollback: restore the tag.

Step 4: utils registry

• Move to the core; Shopfloor re-exports it, and the colour registry imports
  it from the same place.
• Before moving: fix or document the dotted-key limitation.
• Test: the UI suite (theme and colours rendered).
• Rollback: restore the file.

Step 5: base registry

• The core base registry has no profile requirement. Shopfloor's registry is a
  subclass that sets it, and the process and page registries extend the
  subclass.
• Risk: the router guard reads meta.requiresProfile. The subclass must keep
  setting it, or the profile check breaks silently.
• Test: the UI suite (profile selection, navigation, example scenarios) and
  the routes.
• Rollback: restore the base class.

Step 6: auth handler registry

• The core mixin takes the shell; the Shopfloor mixin keeps $root for the
  existing handlers (the api key handler uses it) until they are migrated.
• Test: the login specs (wrong key, valid key, logout).
• Rollback: restore the mixin.

Step 7: transport

• The core transport replaces the transport part of the client. Shopfloor
  keeps:
  • the factory of the base URL (base_url + usage + "/");
  • the SERVICE-CTX-* and app headers, as options or a subclass;
  • the demo client as a second transport, until the demo is extracted.
• in_background calls keep using the standard fetch.
• Test: the UI suite (every spec calls the API), and the demo mode.
• Risk: the endpoint is built in two places. A wrong slash breaks every call,
  which the suite catches at once.
• Rollback: restore the client file.

Step 8: config registry (blocked)

• Blocked on the reactivity decision and on a spike with one key (profile).
• Needs two adapters in Shopfloor:
  • the state adapter, which mirrors the values into the Vue root for the
    templates;
  • the storage adapter, which replaces vue2-storage. It must keep the same
    behaviour: prefix, session storage by default, local storage per key, and
    the time to live from the app info (24 hours by default). A difference
    logs users out or keeps stale data.
• Test: the login specs (session kept on reload, logout clears the storage),
  the language specs (local storage per key).
• Rollback: restore the config registry; the adapters go with it.

Step 9: app shell (last)

• The application logic of the main file moves to the shell. The Vue root
  becomes the state, navigation and i18n adapter, and the template bootstrap.
• Every module taking the root (sync, upgrades, bus) takes the shell instead.
• Test: the full UI suite, the demo mode, and a manual pass on a device.
• Rollback: one revertable change.

Not in this roadmap

• The colour registry: it stays with the theme.
• The demo mock as a separate module: it stays in Shopfloor until the
  transport step is done.
• Vue 3: the adapters are written for Vue 2 first; the Vue 3 adapter is a
  later plan.
• Odoo 16: the same steps apply, with the file paths of that branch.

Test strategy

• The UI suite runs after each step.
• Unit tests for the core (Vitest) start with step 1: each block lands in the
  core with its own unit tests, independent of the browser.
• Each step records the manual checks it needs (fetch events, demo mode).

Open points

• The name of the transport (blocks the naming in step 7, not the work).
• The reactivity design (blocks step 8).
• Whether the core takes the storage time to live, or each app passes its own.