Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show-if inputfields: hide by default, then show #179

Open
Toutouwai opened this issue Apr 18, 2018 · 10 comments
Open

Show-if inputfields: hide by default, then show #179

Toutouwai opened this issue Apr 18, 2018 · 10 comments

Comments

@Toutouwai
Copy link

@Toutouwai Toutouwai commented Apr 18, 2018

Short description of the enhancement

Currently a show-if inputfield is shown by default, and then hidden if the show-if condition evaluates false. This can take a moment or two, so results in a "flash of unhidden content" that can be a bit startling/confusing to users.

My suggestion is that this be reversed, so admin themes have a CSS rule that hides show-if inputfields with display: none (show-if inputfields already receive a InputfieldStateShowIf class), and then once the show-if condition is evaluated true the inputfield is shown (either with an inline style or through the addition of a class). This would avoid the flash of unhidden content.

@adrianbj
Copy link

@adrianbj adrianbj commented Apr 18, 2018

+1
This has bugged me for a long time. FOUCs are one of my pet peeves!

@szabeszg
Copy link

@szabeszg szabeszg commented Apr 18, 2018

This would avoid the flash of unhidden content.

Wouldn't starting with a hidden element introduce another type of "flashing", namely when the inputfield should not be hidden initially (because of the condition evaluating to true)?

@Toutouwai
Copy link
Author

@Toutouwai Toutouwai commented Apr 18, 2018

Wouldn't starting with a hidden element introduce another type of "flashing", namely when the inputfield should not be hidden initially (because of the condition evaluating to true)?

I think that's a lot less problematic because the user doesn't end up seeing something they're not meant to see. Instead of them thinking "what on earth was that?" they are just waiting a fraction longer for an inputfield to appear.

The only way to avoid any visual change is if all inputfields are hidden until the show-if evaluations are completed, but I don't know if we want to go there (e.g. if there is a Javascript error all fields would stay hidden).

@szabeszg
Copy link

@szabeszg szabeszg commented Apr 18, 2018

I think that's a lot less problematic

What if there are other inputfields to its right? Won't they change their positions/widths during this flash? When all inputfield widths in a row do not add up to 100% then things can go weird. Am I overlooking something?

@LostKobrakai
Copy link
Collaborator

@LostKobrakai LostKobrakai commented Apr 18, 2018

Show-If conditions are also calculated on the php side (pw must know which fields to save or not), so there would be the possibility for precalculating the hidden/shown state and letting js just update as soon as it kicks in.

@Toutouwai
Copy link
Author

@Toutouwai Toutouwai commented Apr 18, 2018

there would be the possibility for precalculating the hidden/shown state

I like this idea.

Speaking of the PHP evaluation of show-if/required-if: I think it would be great if the evaluation of these could be divided off from the current protected functions in InputfieldForm to public functions that could have a wider application.

For instance, I think there can be uses for knowing via the API whether a given field will show on a given page, or whether a given page has all its required fields populated. I once looked at making a module to prevent publication of pages from ProcessPageList when the required fields are not populated but the evaluation of the required-if conditions is fairly complex. Now I see the code is already there in InputfieldForm but not in a method that lends itself to a broader use.

@Toutouwai
Copy link
Author

@Toutouwai Toutouwai commented May 26, 2018

I did this as a temporary workaround and it seems to be working well...

In /site/ready.php:

$wire->addHookBefore('Inputfield::render', function(HookEvent $event) {
    $inputfield = $event->object;
    if($inputfield->showIf) $inputfield->addClass('InputfieldStateHidden', 'wrapClass');
});

In some custom admin CSS:

/* Hide show-if inputfields by default (FOUC), but not inside Listers (for example Image fields) */
.InputfieldStateHidden { display:none; }
.AdminDataTable .InputfieldStateHidden { display:block; }

@ryancramerdesign
Copy link
Member

@ryancramerdesign ryancramerdesign commented Feb 26, 2021

@Toutouwai Do you know if this is still the case with current PW versions? I'm not seeing an FOUCs on showIf Inputfields in testing here (AdminThemeUikit). Tested in the page editor as well as in the Template editor. Thanks.

@adrianbj
Copy link

@adrianbj adrianbj commented Feb 26, 2021

Still see lots of them here :)

@Toutouwai
Copy link
Author

@Toutouwai Toutouwai commented Feb 26, 2021

@ryancramerdesign, I think how noticeable the FOUC depends on how many showIf fields exist in the form. If you have a lot of showIf fields the JS evaluation takes longer and the FOUC is more severe. I don't have a test case handy but if @adrianbj is still seeing them then I think the problem must still exist.

In my workaround module, besides the code shown in my post above I have also added this JS:

// Force column width JS to fire when show-if fields are hidden by default
$('.InputfieldStateHidden').each(function() {
	$(document).trigger('hideInputfield', $(this));
});

And in the inputfield render I hook I return early to avoid affecting FormBuilder forms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants