Introduction
This document describes the key design problem statement and design for the separation of the question set and collection editor.
Jira LINK:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Background
Currently, both Collection collection & QuestionSet questionSet editors are using a single code base, and based on configuration collection or question-set editor will be launched. All the BB’s(Knolwg & InQuiry) should work on the same code and follow the same release cycle and github branching strategy(This is very overhead for both teams). Both collection and question-set editors are packaged together. 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.
...
.
...
Problem Statement
How to separate Collection & QuestionSet editorknowlg and inQuiry BB’s can own collection and question set editors independently ?
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
...
build features specific to building blocks ?
How can i get complete ownership of editor instead of depending on other BB’s?
Should able to release independently. (Release process)
Can have own contribution guidelines
Adopter/contributor can take specific editors.
How common code/feature can be shared between editors?
Solution 1: Extending the core editor
In this solution, We have to design and implement a base editor. which will use Which can be extend by the both question set and collection editor.
The base editor will contain the common components such as the hierarchy tree, header, and base service
The Base Editor base editor is also responsible for defining the contract used by itself and the editors to communicate.
Any editors can pick only the components which required from the base editor.
Here’s the diagram architecture of the base editor.
...
Independently deployable and release process (CI/CD pipelines)
Third-party library dependency can be handled independently(Specific to repositories)
Features specific to the editor can be implemented in the respective GitHub repo.
Easier adoption and contribution
Reduce the build size/ better performance
Cons:
Effort intensive
Build and maintenance Ownership of the base editor for contribution
Github Link: https://github.com/vaibhavbhuva/sunbird-editor
...
Here’s sample screenshot:
...
Solution 2: Dynamic loading of the components/fetaures
...
Solution 3: Using shared modules in the single project
In this approach, We 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 applicationthe same project.
For example Hierarchy tree, Dialcodebase service, etc…
...
Pros:
Efficiency: Reuse markups across components, Future changes are simple
Consistency: Updating reusable components get affected everywhere it is used
Very easy to implement
Development effort and testing are less compared to approach 1
Cons:
Any issue with the shared module might affect all applications using it.
Not Independently release process like approach 1.
ConclusionExample screenshot:TBD…..
...