[4.2][Feature] Toggle Field Visibility

[zachweix]

I was looking at #165 by https://github.com/OwenMelbz and I wanted to update it to bring it into line with the current schema for Backpack. In the process, I realized all you need to do is add a few lines to the radio field. You can just add a parameter that this field can be a toggle. The rest of the usage is the same as in that PR. Additionally, one thing that bothered me is that you couldn't hide a field from two toggle fields. Now, I've added functionality that allows two toggle fields choose to hide another field, and then the only way it becomes visible if both toggles allow it to be visible

Usage

//Controller->setUp()
$this->crud->addField([
    'label' => 'Is this a featured article?',
    'name' => 'featured', // can be a real db field, or unique name
    'type' => 'radio',
    'toggle' => true,
    'options' => [ // same as radio, these act as the options, the key is the radio value
        0 => 'Not Featured',
        1 => 'Yes Featured'
    ],
    'hide_when' => [ // these fields hide (by name) when the key matches the radio value
        0 => ['featured_image', 'featured_title'],
        1 => ['basic_title']
    ],
    'default' => 0 // which option to select by default
]);

[scrutinizer-notifier]

The inspection completed: No new issues

[tabacitu]

I love this, @zachweix . It's something people have requested FOR AGES and we haven't gotten to it because it's theoretically easy to do... but indeed... it's drag to have to do it every time.

I have a few questions regarding this:

1. What do you think about providing this as a separate field type? That way it's functionality and documentation is different from the standard radio field? Sort of how we have both select and select2 we could have radio and radio_show_hide (terrible name, just an example). And then the docs for it could be separate, instead of bloating the docs for the radio field type.

2. What field types have you tested this with? What does it currently show/hide?

• address_algolia
• address_google
• browse
• browse_multiple
• base64_image
• checkbox
• checklist
• checklist_dependency
• ckeditor
• color
• color_picker
• custom_html
• date
• date_picker
• date_range
• datetime
• datetime_picker
• easymde
• email
• enum
• hidden
• icon_picker
• image
• month
• number
• page_or_link
• password
• radio
• range
• relationship
• repeatable
• select (1-n relationship)
• select_grouped
• select2 (1-n relationship)
• select_multiple (n-n relationship)
• select2_multiple (n-n relationship)
• select2_nested
• select2_grouped
• select_and_order
• select_from_array
• select2_from_array
• select2_from_ajax
• select2_from_ajax_multiple
• simplemde
• summernote
• table
• text
• textarea
• time
• tinymce
• upload
• upload_multiple
• url
• video
• view
• week
• wysiwyg

PS. I do NOT expect you've tested all of them 😅 Don't worry. I'm just asking. We'll need to do that before the merge though.

[zachweix]

1. At first I was making this a separate field independent of radio, but almost everything is the exact same as the radio field and then any time the radio field's logic changes the other field would also need to match that change. Here we can keep them more in sync. If you disagree with that logic I can separate them.
2. I have to go through my project to see what fields I was using, and I'll get back at that

[zachweix]

I know that it's been forever since you sent this, but I tested this with: text,relationship,textarea,select_from_array,radio,date_range,custom_html (though that can be tricky),checkbox,time
Do you have any idea of when we could try to merge this in?

[tabacitu]

@zachweix , I've had a lot of thought on this. How we can do this in a way people won't keep coming and saying "now I want that field to do the other thing". What do you think of the idea in #4158?

[zachweix]

I like your suggestions in issue 4158, it's a lot to unpack, but to be honest I'm not able to read through the entire conversation from the last 9 days in there. I like that you want to make it more flexible so that it is more future proof. I guess if you don't think you'll be using this, you can close out the PR here

[tabacitu]

I'm not able to read through the entire conversation from the last 9 days in there

I would imagine, yes 😅

Heads-up: I've created the JS library that will help us interact with fields. I think that will be a good starting point for us to merge first... then we can create a PHP syntax that uses the JS library. Not sure on the PHP syntax yet... but we might end up with something very similar to yours! After we're finished with the JS.

Let's close this in favor of #4312 please... and build up from there.

---

Again, thanks a lot for the PR. It's super-appreciated. It's a complicated matter, so a lot of PRs about this didn't get merged (including mine). Please don't let this discourage you from sending other PRs if you have ideas - they're super-welcome and it's how we grow and learn.

Cheers!