Implementation Design of Question Editor and findings

Owned by Vivek Kasture
Last updated: Jan 13, 2023
5 min read

Confluence Doc: Design: Separation of question-set & collection editor

As per the above document, we’ve finalized the following approach:

  • The base editor is not required as a separate NPM package.

  • The Sunbird collection editor can be imported as an NPM package into the questionSet editor or any other editor.

  • All the capabilities/features of the sunbird collection editor will be available in the NPM library, even though questionSet or any other editors are not using those features.

With the above approach in mind, we can separate out all the question-set-related components, and services into a new library (Question-set-editor). This way, we’ll have two separate libraries

  1. editor (All the capabilities needs to create any content collection)

  2. Question Set Editor (Which has all the question-set related capabilities as well as some common capabilities from collection-editor)

Currently, Collection-editor has a lot of capabilities such as creating content collections, units, fancy-tree, various players (including v1 content-player), and CSV upload. Many of the components are not required for Question Set editors such as players, and dial-code. These components are again dependent on third-party libraries.

So, when Question-set-editor imports the collection module, we need to install all the peer-dependencies listed in the collection-editor module, even if we're not using that component.

For example:- If collection-editor is dependent on the @project-sunbird/sunbird-video-player. We need to install dependent packages such as video.js, videojs-contrib-quality-levels and videojs-http-source-selector

To solve this problem, we can use the secondary entry points, it will tree-shake the unwanted code and keep the library modular so that any new user can use the required module and its dependent packages only.

Reference: https://github.com/ng-packagr/ng-packagr/blob/main/docs/secondary-entrypoints.md

Below is the possible folder structure for the collection editor:

Folder Layout

Check out how it is beneficial for any library to have a secondary entry point

As part of the above POC, the following scenarios are checked:

  1. Use the core library

  2. Use the core library with a secondary point

  3. Use a core library having peer-dependency

  4. Use a secondary point with a peer-dependency

  5. Use a secondary point in the lazy-loaded route

  6. Test if a core library has some services. The dial-code module (secondary entry point) also depends on the core services.

  7. Test if the core library has some services. The client component (let's say the question component) also depends on the core services.

  8. Check if all tests are running correctly for all the components (including secondary entry points)

  9. Test whether the internal use of components between secondary points works properly

 

All these scenarios are tested here: https://github.com/itsvick/building-block

I