Introduction
This document describe describes the key design problem statement and design for the separation of question - set and collection editor.
...
Currently, both Collection & QuestionSet editors are using a single code base, and based on configuration collection or question-set editor will be launched. This codebase is currently under Knowlg BB.
This design was implemented when both editors were built and maintained by a single team - sourcing circle. Now, the question set editor is part of inQuiry BB and the collection editor is part of knowlg BB. There is one of the roadmap items for knowlg BB is to separate the question set editor code from Knowlg.
...
Key design problems
How to separate the collection and questionSet editor from the single code - base?
How to create and manage generic components used by both editors?
How to make sure these editors are working as expected after being de-composed?
Design
Approach 1:
In this solution, We have to design and implement a base editor. which will use by the both question - set and collection editor.
The base editor will contains contain the common components such as hierarchy tree, header, and base service
The Base Editor is responsible for defining the contract used by itself and the editors to communicate.
Here’s the diagram architecture of the base editor.
...
PronsPros:
Customize UI
Dependency handling is a bit more flexible
Better separation of features
Improved code splitting when lazy loading modules
Easier adoption and deployment
Reduce the build size/ better performance
...
Approach 3
In this approach, we will build the common components and services as mentioned in the below diagramCommon components and service will be published as NPM package so it can be used by any editors/adaptorsWe will create shared modules which allow us to organise the common code.
We will put commonly used services and components into the shared module and then import just that module wherever you need it in other parts of your application.
For example : Hierarchy tree, Dialcode, etc…
...
Efficiency: Reuse markups across components, Future changes are simple
Consistency: Updating reusable components get affected everywhere it is used
common components can be shared and used by adaptors to build their own editor
Very easy to implement
Development effort and testing are less compared to approach 1
Cons:
Build and maintenance of the common components and service libraryShared modules can not be shared and used by adaptors to build their own editor
Not publishable as an NPM package
Not reusable and customizable like approach 1
Conclusion:
TBD…..