4647.2mysqln/aIf you lazy load a tab which would only otherwise be displayed when all the fields within fulfil their required trigger options the tab is displayed anyway. The tab should only be displayed when the trigger options are complete, eg:
If you click on the Employment Details tab there are no fields until you flick the is_employed switch. Without lazy loading the tab wouldn't be displayed until the fields are triggered - which is the correct behaviour.
admin/october/test/people/update/6This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days.
Bumpity bump
@seanthepottingshed I've taken a look at this for you (and confirmed the bug), however, this looks to be an incompatibility of ideas unfortunately.
The hiding and showing of tabs based on trigger rules work when the fields are present in the HTML (either hidden due to the rules, or visible), however, lazy loaded tabs don't have any HTML until they are loaded for the first time.
This means that if the "Employment Details" tab is hidden by the normal functionality, and I click the "Employed" switch, the tab will still not show because none of the fields are visible in the tab. If I get it to retrieve the fields, then that removes the point of lazy loading the tabs.
We've got a couple of options at this juncture:
@LukeTowers any thoughts on the above?
@bennothommo Thanks for your time researching and confirming the bug, really appreciated.
Obviously updating the documents to advise against using both tab lazy loading and field trigger options would be quickest win, however it would be simply dreamy if both could work.
@bennothommo I believe there was a proposal about the lazyloaded tabs still including trigger attributes and hidden input data containers, but the problem with that is the available options for how a given FormWidget could handle their data lockers in HTML is too varied for us to reliably do so.
I haven't given this one too much thought, but could we include only the field container divs that contain their trigger attributes and not their actual content, and then use those attributes to check if a given field might be impacted by the updating of another field and then at that point load the tab behind the scenes to evaluate the trigger condition?
That still wouldn't work for the opposite direction (trigger condition based on a field in a hidden tab), but that one seems pretty unworkable tbh so I don't think it's worth the time to look into a solution right now.
@LukeTowers my thoughts too. I might just update the docs just to indicate that triggers and lazy tabs are not recommended to be used together, for now.
@bennothommo @LukeTowers thanks for your thoughts and time on this.
@bennothommo could you update the docs as above so we can close this issue for 466?
@LukeTowers already done :) - https://github.com/octobercms/docs/commit/252f2bfdba2321738b07f25b91e1159fa4daf8bf#diff-3253ac7e6278d278efcecb4cf1619b35
Excellent @bennothommo, thanks!
Most helpful comment
@bennothommo @LukeTowers thanks for your thoughts and time on this.