We've identified four approaches that could be taken in order to develop reusable Angular elements:
Approach
Description
No API
Pure angular elements that only expose methods for the outer application to interact with
Indirect API
API access is controlled by the application that the element is embedded into. The element has full access to the API via the current session
Direct API (read only)
The element operates completely independently of the page it is embedded in, making direct read-only calls to a public API
Direct API (read/write)
The element may need to manage authentication in order to directly read/write to the API
Initial priority: The initial approach that we will take to developing Angular elements is to use the indirect API approach.
Indirect API
For our initial work with SURFACE CDMS we are interested in developing the indirect API access approach where Django will manage the session that determines whether the component is able to access the API - where the component and the API are operating at the same domain. When making POST requests, the Angular element will have to pass Django's CSRF token.
The following approaches are not currently a priority, but are documented for completeness:
No API
This approach may be used in the future for small components (e.g. a customised chart) that can be embedded into an application and controlled via methods.
Direct API (read only)
This approach could be useful to add an element to a simple HTML page that is not using JavaScript. The element will get it's data directly from a publicly readable API
Direct API (read/write)
This approach would require an element (or group of elements) on a page to ask the user to authenticate so that JWT can be used with requests. It's not clear whether an Angular element could retain the state if the user navigated away from the current page.
We've identified four approaches that could be taken in order to develop reusable Angular elements:
Initial priority: The initial approach that we will take to developing Angular elements is to use the indirect API approach.
The following approaches are not currently a priority, but are documented for completeness:
No API
This approach may be used in the future for small components (e.g. a customised chart) that can be embedded into an application and controlled via methods.
Direct API (read only)
This approach could be useful to add an element to a simple HTML page that is not using JavaScript. The element will get it's data directly from a publicly readable API
Direct API (read/write)
This approach would require an element (or group of elements) on a page to ask the user to authenticate so that JWT can be used with requests. It's not clear whether an Angular element could retain the state if the user navigated away from the current page.