I guess that the reason that explorer returns to uncollapsed state is that, we do not pass the node element intothis.onDidChangeTreeDataEvent.fire() (This API can accept a node element. Then all the data are cleared before the explorer rerendering.

After some investigations I seems to get the hang of this API. Maybe we can keep another reference container here:

allTreeNodes:Map<string,LeetcodeNode[]>// id -> relative nodes

Then, inupdateProblem function, we can fire events to request all relative nodes to be updated.

@Vigilans Cool. Noticed that now the same problem in the different category has different id. So if we refresh theTwo Sum inAll Problem, will theTwo Sum inDifficulty be refreshed?

That means, I'm thinking that if we should make the same problem has the same id in the whole explorer. Not sure the real behavior of it.

After further investigations, to accomplish this feature, there are some important changes which I think should be discussed in next PR. In this PR, we may temporarily accept the current behavior?

SoupdateProblem() is not used in this PR, right?

Curious about the♥ appearance on different OS platforms, haha.

Any reason we separateallProblems withtreeData?

• allProblems is an id-IProblem dictionary primarily for fast lookup, whose structure is not compatible withtreeData;
• allProblems serves as a buffer which holds all the problems' ownership, where elements intreeData is just references to the problems;
• with regard tothis.onDidChangeTreeDataEvent.fire(problem) review below, we may need another lookup dictionary for fast retrieving relative nodes.allProblems seems more similar to it rather thantreeData.

NowallProblems is decoupled withtreeData, and will be grouped withallTreeNodes as an object pool in next PR.

can we directly comparep.id withproblem.id?

The problems are originally in number-ascending order, thus the comparation in index searching should also be done this way.
e.g. the favorite problems' ids are ["1", "4", "16", "23"], I want to delete the problem with id "23" and id is compared directly. Since "4" >= "23" === true, the search process stops at "4", thus the deletion is incorrect.

IMO, the main problem here is that we store the Favorite problems as an array instead of a Map(id -> Problem).

So you may observe that we have to usefindIndex andsplice to add/remove items, which I think is hard to read.

Can we change it to a Map?

Maybe it can be discussed in subsequent PRs, when updatingtreeData[Category.Company/Tag] field is necessary(delete problem from treeview after it is solved)?

Yes, can be solved in another PR.

The method name her is confusing. Cuz we only handleisFavorite here, but the method name looks like we can update all the fields.

I thought we might handle the case of updating othertreeData fields the at a later time. Seems a overdesign here?
Should I leave a comment announcingmodification of other categories is not needed yet here, or just change the method name?

Make sure now other fields will be updated here in the near PRs, e.g. when a problem is accepted, there will be some code here to update other fields.

Now that we haveelement.parentId,Data.Now() prefix seems no longer necessary.

Btw, the TreeItem Generation code here is separated here for better readability, as well as convenience for next PR(store generated TreeItem somewhere in TreeProvider or LeetCodeNode)

So you will send out another PR to removeelement.parentId &Data.Now(), right?

Data.Now() has already been removed here, which is taken place by element.parentId

We can also support refresh the whole explorer, so the parameter type can be written asLeetCodeNode | null | undefined

You can address it in the next PR

The event fire's parameter isfire(data: T?) where T=LeetCodeNode, so no need to append null and undefined here