Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

This document describe the key design problem statement and design for separation of question-set and collection editor.

Jira LINK: SB-28699 - Getting issue details... STATUS

Background

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 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 editor?

Key design problems

  • How to separate 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 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 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.

Prons:

  1. Customize UI

  2. Dependency handling a bit more flexible

  3. Better separation of features

  4. Improved code splitting when lazy loading modules

  5. Easier adoption and deployment

  6. Reduce the build size/ better performance

Cons:

  1. Effort intensive

  2. Build and maintenance of the base editor

Approach 2

Approach 3

  • In this approach, we will build the common components and services as mentioned in the below diagram

  • Common components and service will be published as NPM package so it can be used by any editors/adaptors.
    For example: Hierarchy tree, Dialcode, etc…

Pros:

  • 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 library

Conclusion:

TBD…..

  • No labels