Add search functionality

[jp7677]

Still work-in-progress, but works already.

[qtzar]

Pulled a clone of this and it is a nice addition.

I do wonder if it would be better to add the search box to the top menu bar instead of it being a page of its own in the side nav. That way it can be accessed from anywhere instead of having to go to the search page first.

[jp7677]

Things to consider/discuss before moving on:

• Note that this is not a server side search, but a client (browser) side search. I guess this wont perform anymore for sites with thousands of ADR/Sections. May be we need an opt-in or opt-out switch for those cases?
• This PR introduces Lunrjs (https://lunrjs.com/ / https://github.com/olivernn/lunr.js ). This package works perfectly here and offers a nice set of features (scoring / search syntax), but development has been silent since 2020. The maintainer has no recent GitHub activity. So not sure if this is a perfect choice?
• The UI is up for discussion. The presentation of the result list is far from beautiful (I'm really no designer) and having (also?) a search field in the header would indeed be nice (doable by passing the search terms by query parameter to the search page). Suggestions for a better presentation of the search results are very welcome.
• Generating the to be indexed documents is currently fine-grained for certain parts of the C4 model. This needs to be extended to also index relations, containers etc. That said, another approach would be to simply look at the generated html files and take the to be indexed text from there. This "brute-force" approach would catch all text (likely to much like table headings) and requires nearly no maintenance for future changes, but we might index things we don't want to index. I'm not sure yet what the better approach is. After playing further with it, the fine-grained approach is definitively better.

~(Obviously unit tests are currently not complete) ~

Any thoughts?

[qtzar]

A possible alternative to lunr could be fuse.js

A quick look at npmtrends shows that it is the most active of any of the lightweight js search engines.
( https://npmtrends.com/fuse.js-vs-lunr)

[jp7677]

@dirkgroot I'm pretty happy now how it works (and looks). Feel free to give it a try. I'm looking forward to your impressions and feedback.

[dirkgroot]

@dirkgroot I'm pretty happy now how it works (and looks). Feel free to give it a try. I'm looking forward to your impressions and feedback.

I like it. It looks nice, and I it's very useful.

I do, however, think that with changes like this, we need to be wary of getting to a point where the code required for the "richer" user experience is getting too hard to maintain.

This tool was never designed with a "rich" user experience in mind, so any JavaScript code added to this will never be a "first class citizen". Nothing is set up for unit testing, or keeping dependencies up-to-date. Adding more stuff like this, will increase the risk of things breaking when changes are made. This is part of the reason why I'm not really keen on merging #180.

However, functionality-wise, I do think that this is a really useful addition.

[jp7677]

I do, however, think that with changes like this, we need to be wary of getting to a point where the code required for the "richer" user experience is getting too hard to maintain.

This tool was never designed with a "rich" user experience in mind, so any JavaScript code added to this will never be a "first class citizen". Nothing is set up for unit testing, or keeping dependencies up-to-date. Adding more stuff like this, will increase the risk of things breaking when changes are made. This is part of the reason why I'm not really keen on merging #180.

yeah, I'm seeing this too. As discussed a while ago, for the long term some real end-to-end tests are needed to mitigate the risks you've mentioned and we should think about how renovate can catch up on client package updates.