A well defined routing will allow users to share backoffice links pointing directly into instance pages (settings, orders, products, etc…)
The backoffice should load from the instance URL and then allow an internal routing of the views with the possibility to accessing them directly when sharing a link.
This 3 definitions are going to be use in this document:
The application is considered ready after
The backoffice test for $BACKEND_URL/config to define if the $BACKEND_URL is ok.
The application can potentially test if the protocol or version matched.
While the application is not ready, just the top navigation bar will be shown with a message in the left and the lang selection option.
There are 2 type of routing: instance and internal
instance: define how the URL will be interpreted to infer which instance is being accessed. Also the full URL is used as default when no BACKEND_URL exist yet in localStorage. After login, the BACKEND_URL is saved in localStorage and the pathname is parsed to infer the instance id.
internal: define which view will be rendered. It is implemented using a hash routing since 1) the SPA is not server side rendered and 2) the http servers doest not need to care about matching all applications URL
Knowing that the $BACKEND_URL points to a correct merchant backend the SPA will
check for $BACKEND_URL/management/instances:
/instances/$INSTANCE. otherwise is
an error. app will continue as admin = falseWhen a user access the SPA there are 3 scenarios possible:
Normally all communication with the backend will be done to $BACKOFFICE_URL and
backend-token will be used used for authentication.
For mimic scenario then backend-token-$INSTANCE is used and the queries
to the merchant are being sent to $BACKEND_URL/instances/$INSTANCE
When the application is ready to start, it queries the backend to test if the user can access to the list of instance and decide if the admin panel should be accessible. See Application routing
All of this entry points are corresponds to the internal routing and is implemented using the hash path. For any entry point that do not require a parameter (like order id or product id) it should be accessible from the Sidebar.
If the user has admin access, this entry points are available:
- /instances: Show the list of instances currently created
- /instance/new: Show an instance creation form
Where admin or not, there is also this entry points:
- / : redirects to the instance settings page
- /update: instance setting page, renders a form and allow modifying it
- /products: list of instance products
- /product/$ID/update: product modification page
- /product/new : product creation page
- /orders : list of instance orders
- /transfers : list of transfers
As an example:
$BACKOFFICE_URL/?instance=foo#/orders will show the orders of the foo
instance, assuming that BACKEND_URL points to the default instance.$BACKOFFICE_URL/#/product/foo/update will show the update page for the
foo product of the instance pointed by $BACKEND_URLIf the application is loaded for the first time a welcoming message is shown with the login form (even if the backend doest not need authentication)
On logout, the application go to the initial state. Removing all backend-token-* from the localStorage
For any case that the backend respond 401 the application will render the login view showing a notification error that the user must check the login credentials or the backend url
For any case that the backend respond 404 the application will render a custom not found page
If the user is admin AND is loading the setting page (/update), product list (/products), order list (/orders) or transfer list (/transfers) AND gets a 404 it will tell the user that it need to create a default instance before proceeding.