I downloaded a new project from start.vaadin.com and saw some new things. The SideNav code is simplified which is good but I’ve some doubts on what advantages it is going to bring
Hi!
I also spotted the new the @Menu annotation quite recently. While I added support for it to Viritin’s MainLayout this week, I made similar notes as you, and also that the “order” is double (int would have been easier for Java developers🤷♂️).
I don’t think you can alone use the Menu to automaticaly build hierarchical menu. For the Viritin’s similar (and much older) @MenuItem, I added parent property. That can refer to an empty marker class (then just simple grouping) or an actual route (then cliking to the parent navigates there). There I sort the next level always separatly → the simple int based order hint works very well there.
Another post I made earlier todo discusses the topic and links to a live demo:
I saw the demo. I’m bit reluctant in using add-ons or 3rd party libraries now a days though they offer more what currently available in the core. The reason is, they go either out of support or dependent on one person/team who stops updating it after some time.
After building a heavy application and seeing the 3rd party stopped updating it completely brakes not only your application but also your life. So, relying on the core is the best is what I relaized after making several mistakes.
The @Menu annotation is to some degree a “demo feature” that might not (yet) be sophisticated enough for use in real-world applications. The biggest limitation is indeed that there is no hierarchy support. This is something that we might add in the future based on the same parent pointer attribute that Matti recently added to Viritin.
The main purpose of the annotation is to help new users get started with Vaadin so that they don’t need to learn about lots of new concepts just to have their newly created view show up in the application’s menu. Just add a simple Java class and you’re done. I would still also expect it to be quite useful also for other simple applications that don’t need a hierarchy.
The reason there is no auto completion for the icon is that we want to support any kind of icon and not limit the selection to some specific icon set like e.g. Line Awesome.
The idea with using a double for the order is to provide an easy way out if you want to quickly test moving things around and there are no available integers to use. So if you have 10 items in your menu
with order values 0 - 9 and realize you want to add a new entry after the first one, then you can just use order = 0.5 to get in between 0 and 1 rather than having to increment all subsequent entires by 1. It might still be good practice to do that kind of cleanup once you’re happy with the new order but the floating point order values does at least give you the possibility of quickly testing things out without updating all other indices.
To me that sounds like the price of open source. But I’d claim your thinking is quite wrong here. Especially if the add-on artifact is in a trusted repository (like Maven Central) with a truly open license like Apache 2, your risk level is pretty much on the same ordinal level as with Vaadin Core as well. In other words you are paying that same price with Vaadin, Spring etc as well.
So whenever you are using OSS (~ getting something for free), you have a risk that you might have to become the maintainer yourself if you need changes in the future, or be ready to pay somebody else for it.
The good thing with the second option (regarding Vaadin add-ons) is that the option exist. That luxury isn’t available for all OSS components. Vaadin (the company) has a lot of engineering power that does exactly that for our customers and they can also fix/extend/contribute-to/fork existing add-ons. Vaadin has also been around for over two decades so there are also lot of Vaadin knowledge outside the Vaadin company, which is great insurance for the users. We (as company) are outsourcing some to one of our partners and I know several other companies who could at any day fork and continue with pretty much any abandoned Vaadin add-on. Also, we have an unofficial community team that has started to maintain several Vaadin add-ons, whose maintainer has for some reason abandoned the project.
Sometimes, there might be other risks/inconveniences to have a direct dependency in your project to some add-on (workarounding company policies, can’t wait the maintainer to cut new version etc). If you are not willing to build your own custom versions of the add-on in this kind of case (which I think should be your primary option), copy-paste-style “dependency management” is just fine as well. So if you for example think the MenuItem annotation in the Viritin would suit for you, don’t be ashamed to copy it (and in this case couple of other classes from the same package) directly to your own project.
But of course the optimal situation is that you use the add-on as such if it works for your, add your own enhancements/fixes to it, contribute them the to the add-on (for which the contrubtion barrier is way lower than in a large project like Vaadin) and later when it is stable enough we can push it (or the core team can bake a solution derived from it) to Vaadin core.
BTW. If you find some add-on that is not e.g. getting support for latest Vaadin versions, and you don’t have the time/money to update it by yourself, asking help on this forum or in the Directory may help. Somebody might get inspired to upgrade/fork it for free.
I did that with your ResizeObserver. I’m good in copy & paste 
Excellent! @Sami is my mentor in a software methodology called “copy-paste-coding” 
@Leif Sounds like there would be some refactoring needs for icons. I have noticed this myself several times that our icon related APIs feel bit cumbersome. Do we have an issue I could follow?
I just want to point out, that there are two types of hierarchy in Side Nav:
Somehow I get the feeling that Matti’s add-on demo would want to use the latter option (hierarchical side nav items). The current version looks a bit odd, when the collapsible side nav labels are visually crammed together with the previous nav item. Usually, you’d want to leave some breathing room between different navs in sidebar (see StarPass as an example).
No existing issue comes to mind so I guess the one you will create is the one to follow 
@Jouni1 there is support for both with the MenuItem annotation, although the online demo only has the ones without targets in use.
I probably abused the components a bit as I wanted to support multiple levels in the hierarchy. Thus using identation instead of vertical spacing for groups. I’m happy to get your perfect styling for it (to my eye at least the indentation is bit too large ATM).
Hi, I’ve noticed a behavior in the vaadin-side-nav-item component regarding its current attribute.
This attribute is only set automatically when the route matches exactly with the one defined in @Route. However, when accessing the view through a @RouteAlias, or when including parameters in the URL (whether route parameters or query parameters), the current attribute does not update correctly.
Is this the expected behavior, or could it be considered a bug?
I’d appreciate any clarification or suggestions on how to handle this case.
It’s expected. You need to use “setMatchNested(true)”
Excellent, that solves my problems. Thank you very much!