Add-on Store: add sub menu items and various improvements

[jimtng]

Resolve #2047

The subsections are implemented as routable tabs, so switching around the different sections is fast.

Installed addons are grouped by category in the main Add-on Store section

Search in the main "Add-on Store" menu will search all types of addons

Search in the corresponding section will only search for add-ons for that category

[relativeci]

Job #1635: Bundle Size — 11.01MiB (+0.01%).

65e7682(current) vs bfa2d4a main#1631(baseline)

Warning

Bundle contains 19 duplicate packages – View duplicate packages

Bundle metrics   2 changes 1 regression

	Current Job #1635	Baseline Job #1631
Initial JS	1.85MiB(+0.15%)	1.84MiB
Initial CSS	607.89KiB	607.89KiB
Cache Invalidation	23.27%	16.99%
Chunks	220	220
Assets	242	242
Modules	3087	3087
Duplicate Modules	164	164
Duplicate Code	1.77%	1.77%
Packages	150	150
Duplicate Packages	18	18

Bundle size by type   2 changes 2 regressions

	Current Job #1635	Baseline Job #1631
JS	9.2MiB (+0.01%)	9.2MiB
CSS	889.44KiB (~+0.01%)	889.39KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	140.74KiB	140.74KiB
HTML	1.24KiB	1.24KiB
Other	871B	871B

---

View job #1635 report View jimtng:addons-submenu branch activity View project dashboard

[jimtng]

What I couldn't figure out: How to push the visits to the sub-sections into the browser's history. Framework7's documentation seems to state that using routable tabs would make that happen automatically, but it doesn't. I tried using history.pushState() but the resulting behaviour is weird, so I took it out.

[jimtng]

@florian-h05 what's the objection for caching the add-ons data? It would get updated anyway so staleness is very minimal. The benefit is a more responsive experience and less twirling circle waiting

[florian-h05]

I have already written a comment but not submitted review yet, so it is not showing app ...

The objection against this way of "caching" is that IMHO caching should be properly implemented on the server side.

[jimtng]

caching should be properly implemented on the server side.

Is there currently a general implementation or mechanism in core for this?

[florian-h05]

Overall LGTM, I have commited some changes.

[florian-h05]

For my addition, see #2221.

[florian-h05]

For what is this required? I have removed it and not noticed any problems.

[florian-h05]

Is there currently a general implementation or mechanism in core for this?

As the REST endpoints have different data sources, there is no general implementation.
Usually, RegistryChangeListeners are used to listen for data changes, but in some cases other ways of "watching" for changes need to be used.
I am currently working on a caching implementation for the add-ons endpoint.

[florian-h05]

@jimtng Ready to merge?

[jimtng]

Thanks for the review and fixes. I wish the caching stayed in but hopefully the server side implementation you're working on will work as well.

[jimtng]

@jimtng Ready to merge?

Yes thanks

[ghys]

Hm, for the record, I had mixed feelings about this PR butchering my design for the original add-on store... :/
I just wish I had more time to express them and have a discussion.
(and yes I'm aware of the discussion at https://community.openhab.org/t/ideas-for-new-openhab-installation-experience/154042/).

I guess you'll find the flaws in this design in time. Or not.

But I'm okay with having no agency over this as I'm not really active.

[florian-h05]

What is your biggest concern with the new design?

I personally like it overall and thing especially having a search at each tab is very practical.
But I’m still unsure what is more practical for navigation: The old tab bar or the side menu entries.

[ghys]

To be honest I wasn't sure of the ability to navigate the add-on store on narrow screens but after all I think it's okay - for now:

The bottom toolbar (which I thought initially to be removed) is nice but is becoming quite crowded.
This is why I made the add-on store initially about 3 main concepts: bindings, automation, UI (and the rest in a 4th tab, and universal search in a 5th tab).

[florian-h05]

I added the toolbar for those devices where the sidebar is not permanently available and have also noticed that it is crowded.
Having one icon less in the tab bar would already help with the space.

[jimtng]

Tbh I've never tried accessing the main UI from a mobile phone, but now I've just tried it.

I've noticed several things:

• Because the focus goes to the search bar every time I switched to a new tab, it's annoying that the keyboard would pop up an converting up half the screen

• The suggested and recommended items seem too big and take up a lot of space (same in the old design)

• I'm not 100% happy with the main "add-ons" tab showing only the installed add-ons. I'd like each section to have a little link or button for "more" that goes to the corresponding tab. But that may be redundant with the bottom tab bar?

• Now I better understand why having Smart selects aligned to the left isn't the best idea for a narrow screen! Up until now I've only been using main UI from a desktop

This has been a learning experience for me. I will try to amend this.

• the native back button navigation from the phone (on the bottom of all screens) often caused main UI to break/freeze. This is occurring in a few places in main UI (eg item editor in dirty situation). I'm still not familiar with f7's route and path history. The same issue happens on desktop and it has been a long time annoyance for me but this is for a separate topic.

[ghys]

Tbh I've never tried accessing the main UI from a mobile phone

This is indeed a problem and something that you MUST do before altering designs.
You just have to test your changes with the 3 themes, both dark & light, and on various devices before you submit impactful changes.
We have 3 seats available on our sponsored BrowserStack team and I'm happy to give one to you as you seem to be serious about developing the UI. Just reach out with an email address in private on the forum.