...
The driving idea behind most of the dashboard implementation is that in FOLIO we rely on want the frontend to drive crossthe inter-app interactions through API calls, and so the backend mostly acts as a storage and resolution point for the frontend app.
...
The ethos then for this app overall is that we wanted there is a tight set of WidgetTypes, which will be curated and developed very carefully. Since we plan to keep this as the available WidgetTypes is a closed list, we can assume absolutely implicitly the structure of any Definitions/Instances coming into the system can be absolutely implicitly assumed, allowing us to build our frontend code to be built around that.
The idea is that once Once the frontend work is done for a particular widgetType, any new widgetDefinition to use using that widgetType should just work, complete with:
...
Adding a new definition for an existing type should be no more than an hour-or-so's work, very straightforward with minimal investment from the developer. To add a new Definition for an existing Type will require first reading and comprehending the JSON schema for that Type, along with any existing WidgetDefinitions for it, and then writing JSON for your own backend which fits that profile. As stated above, that JSON document should be the beginning and the end of your the development work needed to get, say, a SimpleSearch widget for a specific resource to display, and be an option for a user to configure, complete with a fully functional dynamic form to set that widget up.
...
Backend Ethos
Specific to the backend, we intend to use this both as this is intended as both storage for the dashboard, but and also to include a "frontend registry. The idea here is that mod-service-interaction ". This registry will be able to act as a point of interaction between the frontend and backend, able to return information about differing frontend apps, such as how their url filtering is built, allowing other apps then to make a call to mod-service-interaction and use that information to create pre-filtered links on the fly. Similarly we can use this in the dashboard to offer solutions such as custom display components from apps within tables.
Another use for the backend app is as a place for user-specific information. Similarly to how the dashboard is shown per user, we can also use in future this app in future could be used to store other information a user might want to have specific to themselves.
...
Reusability and Extensibility
The idea dashboard is to not tie this tied exclusively to ERM in any meaningful way. This way any build can potentially make use of this service/app, and we can attempt to have cohesion and similarity of design no matter which users are using this app, and which module's widgets they're attempting to add to their dashboard.
As part of this we aim to build The overall aim is for a system where new definitions can be added automatically by other modules, requiring absolutely zero work from our the ERM team. Simply send your New Definitions for a Type and see your widgets can be POSTed on the fly, and they will appear as options in your systemconfiguration options for users without any development work besides the JSON file.
We hope the backend module mod-service-interaction can become a storage point for certain frontend information, allowing this kind of inter-app interaction as smoothly as possible for both the dashboard, and also any other apps which need this information.
Finally, with all of the components for ui-dashboard we are aiming to be as simple and reusable as possible. A good example is the DragAndDropFieldArray, which we have has been designed not just for our ERM specific use casecases, but to work in general anywhere it would be useful to reorder a FieldArray within a FinalForm component. With these we hope to provide both a useful frontend app, but also tools and patterns other frontend developers can use within their own builds.