It would be better to put theIProblem definition andIProblemDefault to other places instead of in this file.
Let's put them intoshared.ts, I'll refactor this part later.

Usefs-extra

We can usereadFile fromfs-extra.

Something went wrong with my usage.fs-extra is correct.

Can we import the module?

For example,npm i --save-dev @types/require-from-string
Then import it instead of using require

Yeah, thedefinitelyTyped indeed provides type forrequire-from-string.
import * as requireFromString from "require-from-string"; successfully worked.

Can we use enum instead?

TheLeetCodeTreeDataProvider.treeData needs the type semantic fromCategory to preserve the type hint, whereas enum just provides the value semantic.

Without the string union type,this line won't get proper type hint:

constproblems:list.IProblem[]|undefined=this.treeData[parent].get(subCategory);

this.treeData[parent] will returnany type.

If we changeCategory to enum type, then the above line should be rewritten to:

this.treeData[parent.toString()as"Difficulty"|"Tag"|"Company"]

which falls back to where it starts.

Have you tried this:

exportenumCategory{Difficulty="Difficulty",Tag="Tag",Company="Company",}

After trying,Category.Tag.toString() only returns typestring.

There is no one-line way to get the type hint here, reference:
https://stackoverflow.com/questions/52370544/parse-string-as-typescript-enum/
https://stackoverflow.com/questions/52393730/typescript-string-literal-union-type-from-enum

No need to call.toString() here.

Whenever you want to use the Category value as a string, just usingCategory.xxxx.

By doing this, you will get the value as a string meanwhile keep the typedef.

I tried using enum here and everything works fine.

Let's make theCategory enum type:

exportenumCategory{Difficulty="Difficulty",Tag="Tag",Company="Company",}

Then rewriteline 147 this way:

constcategories:Map<Category,string[]>=newMap<Category,string[]>([[Category.Difficulty,[problem.difficulty]],[Category.Tag,problem.tags],[Category.Company,problem.companies],]);

Follows the iteration:

for(const[parent,children]ofcategories){for(letsubCategoryofchildren){

Here,typeof parent isCategory:

Continues theline 156:

constproblems:list.IProblem[]|undefined=this.treeData[parent].get(subCategory);

Sincetypeof parent isCategory andthis.treeData's key type isstring,get's type could not be deduced from the usage, and there's no way to useCategory.xxxx here:

Meanwhile, we couldn't changethis.treeData type toMap<Category, Map<string, list.IProblem[]>> since there is a fieldFavorite which doesn't processed asCategory and its value type islist.IProblem[].

If you insist to use enum here, a workaround could be:

private treeData:{[Category.Difficulty]:Map<string,list.IProblem[]>,[Category.Tag]:Map<string,list.IProblem[]>,[Category.Company]:Map<string,list.IProblem[]>,Favorite:list.IProblem[],};

Nowget's type could be deduced properly:

Yet I think it complicates what could have been an easy and elegant solution in Typescript.

We need to write more hard-coded strings if using string union here while using enum can get rid of this. That's the reason I prefer using enum here: make the code easier to maintain in the future.

There are many ways to get rid of the special fieldFavorite. One simple way to do a simple check before getting the map. TS will help us to infer the type during compilation.

I'm thinking that we can filter the accepted problems in the methodlist.listProblems(). IfhideSolved === true then only return unaccepted problems.

By doing this, we decouple thethis.leetCodeConfig with the explorer

In my opinion,Favorite group should show all starred problems no matter whether it's accepted or not.

Maybe it could be checked this way inlist.listProblems():
!problem.favorite && problem.state === ProblemState.AC && hideSolved ->continue
The flaw is that the favorite checking logic is duplicated.

Hmm, ok, just keep it there first.

Can we use Map here?

use index to represent theparent-children relationship is confusing

We could use Map here this way:

constcategories:Map<Category,string[]>=newMap<Category,string[]>([["Difficulty",[problem.difficulty]],["Tag",problem.tags],["Company",problem.companies],]);

Btw, a better way would be to useObject.entries here, but it is not supported by es6, which is specified bytsconfig.json.

Let's use Map here.

first-second is not that bad.

Cuz current logic could handlea-b but nota-b-c

Just leavefirst-second as it is for now.

What doesa-b-c refer to? The code here could transformbreadth-first-search toBreadth First Search.

My bad, it's fine.

Why we save parent node name intoelement.id?

There should be some field to store the parent node name when it is not problem node...since in previous commits you simply setnode.id andnode.name the same value, I decided to reuse theid field to represent some other value.

The reasons for the necessity of parent node name are:

1. We should be able to retrieve data from theLeetCodeTreeDataProvider.treeData.
2. One problem will now be added asLeetCodeNode at least 3 times(inDifficulty,Tag andCompany), we should be able to distinguish them, hence the following naming rule:

id:`${idPrefix}.${element.id}.${element.name}`,

(idPrefix = Date.now() just returns same value throughout initialization process)

Maybe we could add a filed in theLeetCodeNode called 'parentName' to store the parent node info.