Comment by Gigachad
5 years ago
It needs to so that it can search on the backend and show you all instances of that search rather than just what the currently loaded DOM elements contain.
5 years ago
It needs to so that it can search on the backend and show you all instances of that search rather than just what the currently loaded DOM elements contain.
On pretty much any other web page, Ctrl+F will search whatever is on the page; why should Discourse be any different?
I don't mind them having a server-side search function that actually searches the entire thread. I do mind having a heavily-used shortcut hijacked to behave in a non-standard way.
Try pressing CTRL+F twice and see what happens
Oh, I'm well aware of this workaround. The problem is that Ctrl+F is muscle memory by now, so I usually hit it and immediately start typing... then notice that it's the wrong search, swear, hit it again, and type again.
Because to remain performant, modem sites remove elements that have been scrolled too far off the page. So native ctrl + f would not be searching very much at all.
I don't see the problem with this tbh. When you create a JS app, you lose a lot of the native features of the browser and it becomes your own responsibility to reimplement them in a correct way. As long as the site pulls it off flawlessly, this is ok to me.
And from what I have seen, discourse does do this well.
> to remain performant, modem sites remove elements that have been scrolled too far off the page
This is done to remain performant specifically when the website thinks infinite scrolling is a good idea. In my experience it very rarely is, with the Ctrl+F thing being just one of the reasons why.
This is a great example of a "feature" that seems to make sense but, for reasons I can't quite put my finger on, really bothers me.
Maybe it's that Discourse's search functionality didn't really work well, or suddenly started searching across threads rather than only the current one (IIRC); maybe it's that it's the only system I can think of (other than google docs) that hijacks the shortcut, but it gave me a very negative first impression of the tool.
For another similar example, the Blendle website (note - not the app!) hijacks Esc when reading an article, and interprets it as a shortcut to return to the main page of the site. I actually reported it as an issue to them, and they said it's by design and not going to change. :/
What if I want to search only currently loaded DOM elements?
Usually you repeat the search hotkey to activate the browser's native search function.
On most modern apps, this is pretty much just what is on the screen right now + a little on the top and bottom. The elements get removed/reused once they scroll off the page for performance.
I only see this as an issue if the site does not reimplement find so that it is able to deal with this.
Why can’t we just use normal forum software from the 2000s, but with security patches?
5 replies →
That seems like a direct consequence of the non efficient infinite scrolling that they implemented.
Their method seems really efficient to me. It infinitely scrolls, feels like it's actually native, and hijacks the shortcuts to make them work as if it was native.
I really like their timeline scrollbar as well which lets you easily move through hundreds of posts very quickly and has become a pattern in many apps like Google Photos and Telegram.
It does not hijack the shortcuts to "work as if it was native", because there's no way to know how the native function works in every browser, in most cases.
Let's look at Ctrl+F again. The standard Chrome search toolbar is search-as-you-type, highlighting occurrences immediately. It also shows the total number of occurences found on the page, and has arrows to navigate to next/previous. It also doesn't auto-hide (and thus lose focus) if you scroll the page.
What does Discourse replace it with? A search toolbar that requires an explicit submission to even start searching - and then, instead of actually scrolling to the occurrence of the search term, it shows a dropdown with snippets of posts in current scope that matched the term, highlighting it much like a search engine would.
So it basically has nothing to do with the native function that it hijacks, other than the broad concept of textual search.
What do you mean by "native" here? Is pagination non-native?