Add dropdowns instead of chips

[RKBoss6]

Adds dropdowns instead of chips as per BangleApps #4150. Also adds a new sort method, 'explore', which is a random shuffle so users can explore new apps that are otherwise buried beneath more installed apps. The PR also implements dropdown menu aligning, so if it goes over the edge, it aligns to the other side instead for seamless UX

[gfwilliams]

Thanks - is the available for testing somewhere?

Please can you sort out the lint warnings? The padding, but also chips in chips.indexOf(searchValue) not being defined doesn't seem great.

Can you rename explore to random as well? I think many users would assume that Explore was something more complex than random ordering, and we'll likely get complaints when just clicking Install/Update/etc on an app will cause the list to be updated and will re-order everything.

I'm also a little concerned about the autoAlignMenu function - are you sure we can't just achieve what we need to using bare CSS? We've managed to make it this far without needing anything, and every time I've used JS for alignment it's usually come back to haunt me at some point.

[RKBoss6]

Hi! This is available for testing on my app loader. As for auto align, I tried looking in a bunch of places to see about it, and there's just no way we can get something like that in pure css that works in all platforms. The align feature reacts to resizing the webpage, and has worked really well for all the times I've tested it, so I think it'll be fine. It's a good point about the explore option, I can change that!

[Copilot]

Pull request overview

Updates the app loader library UI to use dropdown menus (instead of chip controls) for filtering/sorting, adds a new “explore”/randomized sorting mode, and introduces automatic dropdown menu alignment to avoid viewport overflow.

Changes:

• Switch filter/sort UI logic from chip-based selection to dropdown-based selection (anchors/menu items).
• Add a random shuffle sort mode for “Explore” browsing.
• Auto-align dropdown menus to the left/right depending on available viewport space.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gfwilliams]

Please could you also add:

if (document.querySelectorAll(".chip").length)
  console.error("This EspruinoAppLoaderCore expects app types in a drop-down, not chips. See https://github.com/espruino/BangleApps/pull/4150/changes");

I don't know if we need any other checks, but that should really help for people updating AppLoaderCore on other app loaders like https://espruino.github.io/EspruinoApps/

[RKBoss6]

Alright, I think this looks good now. I know there's some changes to be made in #4150, but this looks pretty good to me - @gfwilliams do you see anything?

[gfwilliams]

I'm not a big fan of faea018 (edit: which went in since your comment!) - in fact I think it actually undoes a fix I intentionally made before.

The problem is:

Suppose I want the assisted GPS updater. I type agps into search, and I'd expect to get the most relevant search result. In the old app loader (https://banglejs.com/apps/?q=agps) I do, but in yours (https://rkboss6.github.io/BangleApps/?q=agps) I now get A-GPS Data Downloader App because that's the one with the most installs because the AGPS updater literally can't be installed.

Or maybe a better example: I want 'pebble clock' so I type in pebble. But in the new app loader I get 93 dub because any app with pebble anywhere in the name/description/tags gets pulled up and then they're sorted by whatever the sort was set to.

But there are a bunch other times this plays havok and it was really annoying when trying to find stuff. Maybe if you don't want it to do it, you should make the sort drop-down default to none if search is used? But personally I think the current behaviour is fine, as I do want to sort by popularity normally, but when I'm searching I really do want the most relevant result.

But in general please can you try and keep the scope of the PRs down? I know it's tempting to see something and try and stick a fix in the same PR for it, but for me it's a moving target - I look one time and it seems fine, and then the next time I look something's got broken.

I'd much rather (as I think you would!) to have smaller PRs that can be checked and merged quickly, rather than having ones that I'm repeatedly annoying you by making requests on :)

[gfwilliams]

... also the old app loader defaulted to Favourited as the sort type. I think it'd be nice to keep that (rather than None) as the average user will be better served installing the app more people like.

[gfwilliams]

I should also point out that the old sort implementation did actually sort by the selected sort method when searching, but only if the search relevance for the thing that was searched for was actually the same (which seems sensible).

It's just that (and I'm not sure why) often the search relevance was different, so that takes priority. For instance if I type 'clock' in search and then flip through sort options, they only really start to change around app 29!

[RKBoss6]

Ah, I see. Yeah, I completely agree with the small PRs - I just didn't keep track of what was working and what wasn't before I merged everything together with the changes from #89 and before, and thought something had broken with this during the merge. I'll revert the changes now, sorry about the mix-up!