Bug - Beta v24 - QRouteTab no longer binding router specific attributes to HTML tag
nicholaszuccarelli opened this issue · 9 comments
Using QRouteTab is no longer binding router-specific classes and attributes to the actual HTML element.
For example, on the regular version of Quasar, my QRouteTabs will each have classes "q-router-link", "q-router-link--active" (etc), and a href="" attribute for SEO purposes, however after switching to this branch, all these properties no longer exist on the QRouteTab attributes.
Clicking the actual tab still correctly redirects to the defined to prop, but as mentioned, the actual HTML source doesn't display the href=' attribute making it invalid for SEO.
(This problem doesn't exist for QTab acting as a route - they still correctly bind the attributes)
Can you check if you really had q-router-link class on the tabs (and it is not added by you) - I'm not talking about q-router-link--active?
Yep, I compared the running code on our production server and I certainly didn't add the classes manually. Code was identical, except one was running on beta v24.
q-router-link?
Both don't have q-router-link.
Below is when the router tab is active.
On v24 beta: (Notice how href is also missing)
On production (v1.16 official)
That was what I was asking, because there was no q-router-link before and I needed to confirm your:
my QRouteTabs will each have classes "q-router-link", "q-router-link--active" (etc)
Oh my bad then, sorry about that. I should clarify that the q-router-link--active classes etc aren't being bound anymore, but instead using q-tab--active. Plus href not being bound either.
The q-router-link--active one I suppose can be bound using the exact-active-class prop (unless it is actually a bug).
All the rest is done :) but that class q-router-link puzzled me because it was nowhere in original Q1
Haha sorry again. And thanks a lot for fixing the three bugs. I will continue testing the version tomorrow and report back if I find anything else. Rest seems solid so far.