[Feature] Chips

[tabacitu]

The problem

Sometimes, the admin cannot identify an entry based on one attribute alone. Some examples:

• for an Order, it's not really useful for the admin to see the order ID, nor the name, nor the email, nor the phone number; a combination of them... is what would actually help them identify the Order;
• for a Ticket (eg. ticket for a show), it's exactly the same... seeing the ticket hash (eg. PPNK7I0-EFQECS9OOSBOY4JY-TEZSWCA4H) tells the admin NOTHING - they would like to see a combo of ticket owner email, phone, maybe ticket category - something;

To counter the above, what often ends up happening in the List and Show operation... is that we developers add a column for EACH of the attributes the admin can use to identify that entry. But when you add SO MANY columns... they get hidden by DataTable... or you make the table scrollable horizontally which is a terrible UX.

The solution

Instead of showing ONE attribute inside ONE column... what I've been doing in my projects is to add what I call CHIPS. Blade files that GROUP multiple attributes in a tiny space... so as to show A LOT of information, packed together. For example:

Orders

Instead of requiring 9 columns, I could basically group 5 columns inside a "order chip"... then use that chip as the first column:

But because that chip does SUCH a great job at showing all needed information about an Order, in a small footprint... I could also use that exact same chip somewhere else... for example in a Show Ticket page - instead of just showing the ID of the order it belongs to... I can show the order chip:

Tickets

Instead of requiring 9 columns, I could basically group 3 columns inside a "ticket chip"... then use that chip as the first column:

But because it does such a great job at identifying a ticket... I also used it at the TOP of my Show Ticket operation, as basically a header for that page:

Other examples

The implementation

It's actually pretty easy to do a custom chip... it's just a blade file... that you can then use as a column. BUT. There are a few gotchas:

• if a chip contains related info (eg. the chip of a Ticket also has ticket.category.name) you prooobably need to eager-load that relationship;
• there are probably UNLIMITED ways people will want to customize the chips, depending on their information; so our template can cover x% of the cases, but what's important here is to give devs the option to easily create CUSTOM CHIPS; I believe that will be used more than default chips;

The todos

To have a draft PR for chips, I think we need to:

• create a resources/views/crud/chips directory, with a default.blade.php chip that uses the format above, and allows devs to echo a Title (with link) and a subtitle (muted, grey);
• provide a way to easily use chips as columns or widgets or blade files; and document those ways;
• provide a command to easily create a custom chip, for a certain entity; then to use that chip as a column or a widget;
• provide examples of 5-10 chip designs, to make it easier for developers to create custom chips by getting inspiration from the examples in the docs (or straight-out copying the code from there);

I don't know if we should go any deeper... for example to have the chip actually use the Backpack columns inside them... I kinda think that is overkill.

[tabacitu]

Done in #5815
Documented in Laravel-Backpack/docs#631
Demoed in Laravel-Backpack/demo#701