Some more refactoring ideas

[ang-zeyu]

Is your request related to a problem?

• Combine page nav and search heading indexing (Auto-search content of pages #205) into one inside NodeProcessor, possibly managed in-memory by some Indexer abstraction of sorts (d.moderate)
  • both contains very similar duplicate logic (e.g. don't index unexpanded panel's content, but index its header)
  • the latter is performance hungry, requiring re-reading and parsing html files of Externals
• Split up NodeProcessor further into separate files (d.easy)
• Separate site conversion (d.easy) and live reload logic (d.moderate) from Site.js
• PageConfig has a lot of duplicate properties with SiteConfig - pass down and use site config where appropriate (d.easy) #1986
• Almost-redo Tab, Tabset, Tabgroup using vue provide/inject api for better template isolation (d.moderate)

[raysonkoh]

Just to clarify for the second point regarding splitting up NodeProcessor into separate files, I am thinking of separating the methods that are specific to the various components such as _processQOption, _processQuiz, _processTooltip to a separate file (maybe componentProcessor?). @ang-zeyu Is this what you meant? 😅

[ang-zeyu]

Just to clarify for the second point regarding splitting up NodeProcessor into separate files, I am thinking of separating the methods that are specific to the various components such as _processQOption, _processQuiz, _processTooltip to a separate file (maybe componentProcessor?). @ang-zeyu Is this what you meant? 😅

@raysonkoh sorry for the overly brief description. I was thinking it might be more cohesive to group things by functionality here, so you know right away what a file contains only. (quicker to grasp instead of going through each component file and figuring what goes on for each component)

E.g. iirc, some main functions left are:

• rendering markdown-in-attributes into slots
• combining / shifting footnotes from included files into one giant chunk at the end
• heading id assignment
• bootstrap vue transformations for modals, popovers, tooltips
• deprecation warnings (**might be able to resolve this completely in Fully deprecate some component attributes #1504 first though)
• ...

Organising by components might be ok too though, also some components / elements only have 1 functionality - if it turns out better let's go for that.

[tlylt]

Additional refactoring ideas putting here for discussion:

• Consolidate frontmatter handling to its own class/file
• Consolidate asset handling to its own class/file

[tlylt]

For Pt 3,

Separate site conversion (d.easy) and live reload logic (d.moderate) from Site.js

@ang-zeyu May I know if you have any suggestions on where site conversion and live reload logic should be shifted to? A new class/file? Not sure what kind of separation works best here.

[ang-zeyu]

Site conversion

iirc this process is fairly "pure", so we could probably just extract this into a function in another file, and call that in Site.js.

Site.js

Something along the lines of the above if possible. This part is rather coupled iirc so there might be some difficulty there.

Would also suggest completing the typescript migration before any of this to prevent silly regressions =P.