Support --subjects as csv

[abdulazimRabie]

Fix : #271

Approach:

• Add --subjects to parameterList as a CLI option
• Verify that passed subjects are valid and match with rootCategories and cats
• Select both cats and rootCategories values based on passed values.

e.g : --subjects 'math, physics'

• cats : {4: 'physics', 15: 'math'}
• rootCategories : [Math, Physics]
• simTree (if en,mo passed as includeLangauges):

en: {
    'atomic-interactions': [ 'Physics' ],
    'balancing-act': [ 'Physics', 'Math' ],
    .....
}

 mo: {
    'atomic-interactions': [ 'Physics' ],
    'balancing-act': [ 'Physics', 'Math' ],
    ......
}

Note:

• I have added formatcsv as a util function for all future csv parameters.

[abdulazimRabie]

I think that we can write better code if we are having tow options

• --subjects : for main categories [Math, Physics, ...]
• --subSubjects: for sub categories [motion, gravity, ...]

If this is done, we can handle rootCategories by --subjects value , and handle cats by --subSubjects

[benoit74]

I don't get how this code is supposed to work.

Can you please explain how to build (command to use) and provide a ZIM with only Biology exercises in English? I tried but it produced a ZIM with all exercises.

[abdulazimRabie]

@benoit74 , I've made some changes. Now you can try phet2zim --includeLanguages 'en' --subjects 'biology'. Exported ZIM file must contain 7 exercises of biology in English.

Please, try also a combination of subjects :
phet2zim --includeLanguages 'en' --subjects 'biology, quantum, sound & waves'

[benoit74]

You should import options from export step, not get

[benoit74]

This is misleading, text above says this is available only on GET step while --subjects MUST be passed to both GET and EXPORT steps

[benoit74]

Why do we need to slugify the subject? (not saying this is wrong, but it probably deserves a comment)

[abdulazimRabie]

I found that each time I deal with subjects (as array), I need to slugify all subjects again. So, i preferred to slugify all subjects from the beginning.

It also will reduce calling slugify to make code more readable.

Is it right ?

[benoit74]

I don't get it, sorry. Where are the subjects slugified in the first place? Why are they sluglified at this stage?

[abdulazimRabie]

First , When I need to verify subjects (ensure that inputs are already existed in cats) , I use cats values (which are slugified). So, I need to slugify (input subjects). This happens in verifySubjects function.

Second, When I return only matched cats, I need to slugify the input subjects again

Over all , I try to avoid this : calling formatcsv (I prefer formatSubjects) and a lot of slugify(sub, {lower:true})

export const verifySubjects = (subjects: string): boolean => {
  return formatcsv(subjects).every((subj) => {
    return Object.values(cats).includes(slugify(subj, { lower: true }))
  })
}

export const getMatchedCats = (input: string) => {
  const formatedSubjects = formatcsv(input)
  const catsKeys = Object.keys(cats)
  const catsValues = Object.values(cats)
  const validCats = {}

  formatedSubjects.forEach((sub) => {
    const indexCat = catsValues.indexOf(slugify(sub, { lower: true }))
    if (indexCat >= 0) validCats[catsKeys[indexCat]] = catsValues[indexCat]
  })
  return validCats
}

[abdulazimRabie]

If you think there's no need for that. It's totally OK.

[benoit74]

I don't get why we lookup indexes to verify subject validity, wouldn't it be enough to check that all subjects are among categories?

[abdulazimRabie]

@benoit74 , I've fixed requested changes.