Quick ajax button with swal response

[susanu]

Hi,

I am currently migrating from backpack version 5 to version 6 and i had some buttons with statistics across multiple cruds.
The way i implemented this in v5 is:

1. Create a new widget type called button that you can fully customize from the CRUD
2. Added some javascript that would make ajax requests and return data in json format
3. Display the data into a sweet alert popup

I want to use the quick button functionality for this and i saw that you support ajax requests.
Do you think supporting sweet alerts also make sense?

Thank you!

[pxpm]

Hey @susanu thanks for the suggestion.

I do think swal looks better than noty, but our use-case when we added ajax functionality to the quick buttons was to not have blocking alerts on the page, só that you could quickly fire 5, 6, 7 ... ajax calls at the "same" time without blocking the page.

I wouldn't mind if we had an easy way to set the alert type (noty/swal), at the moment we don't have, and just cramming a big if(swal) there will make this button a mess in no time.

I am going to spitball some ideas here, but please don't start working on anything I talk here, I am not even sure if it would work.

What I think would be "clean", was for us to create our own BackpackNotification class in javascript, that can operate with both noty/swal, and from the quick button we just call it: BackpackNotification.swal(title, text) or BackpackNotification.fire('swal', title, text).

In the quick button configuration we could accept a notification key that would allow the developer to setup the alerts for that button:

CRUD::button('test)->type('quick')->meta([
'ajax' => true,
'notifications' => [
    'type' => 'swal',
]

OR, not sure if better or not, allow that configuration to come with the response alongside the messages ?

Why do I think this would be an interesting use case to pursue ? Because if done correctly, we can allow ALL backpack notifications anywhere (list, create etc) to be configurable by developer if he would prefer swal or noty.

What you think of what I've said ? Looks reasonable to do ?

Cheers

[susanu]

I really like the approach, i think this will cover my use case.

One more suggestion would be to upgrade the sweet alert to version 2 and replace all noty notification with sweet alert since it has support for custom placed alerts.
I know this is a breaking change, maybe this will be fit for the next version of backpack.
In the meantime, i will preserve the code from backpack v5 since it covers my use case and upgrade when this will be implemented.

Here is my current code (with a simple example):

• Button configuration

CRUD::button('show_products_statistics')->stack('top')->view('crud::buttons.quick')->meta([
    'access' => true,
    'icon' => 'lar la-chart-bar',
    'wrapper' => [
        'element' => 'button',
        'href' => 'javascript:void(0)',
        'data-button-type' => 'swal',
        'data-include-query' => 1,
        'data-route' => backpack_url("{$this->crud->route}/products-type-statistics"),
    ],
]);

• Javascript code

$('body').on('click', '[data-button-type="swal"]', function() {
    var queryString = '';
    if($(this).attr('data-include-query') === '1') {
        queryString = getQueryString();
    }

    const $this = $(this);

    $.get($(this).attr('data-route') + queryString, function (result) {
        if (!result.success) {
            new Noty({type: "error", text: "<strong>" + result.message + "</strong>"}).show();
            return;
        }

        swal({
            title: result.title,
            content: $(result.content)[0],
        });
    });
});

• AJAX response example

return response()->json([
    'success' => true,
    'title' => 'Total number of products',
    'content' => '<div class="text-start"><ul><li><b>SKU</b>: 12</li><li><b>SKU_2</b>: 100</li></ul></div>'
]);

[pxpm]

Interesting, thanks for sharing you solution @susanu

When we discussed this feature @karandatwani92 also had proposed we used two different types of alerts, but given the use case, his proposal was to use blocking swals on error, and non-blocking noty on success. If we had gone that route you now would be asking how to invert the behavior 🙃

I think the only thing that could cater to both scenarios is making the notifications somewhat configurable. Probably like you suggested, the most correct approach would be to ditch noty and use sweetalert2 (a fork of it without the russian issue) for all our notifications as like you said it also support toasts.

That would be the step 1 to avoid having different docs depending on the notification type.
Second thing we need to think is how we want to make the configuration process. Because most likely you also want to configure buttons ? Animation times ? etc, basically the configuration provided by sweetalert2.

I think having a common place to define notifications goes along way of cleaning the notifications in backpack. At the moment the notification logic is all around the place, you can add noty's from php with Alert:: but not swals .. it's also a pita to maintain when it's required to add a class or similar you need to touch a bunch of files.

I think working in supporting noty and swal to ditch noty or whatever we decide to do it's not wise now, I will open a issue in crud and tag it for next version so that we discuss it 👍

Thanks for the suggestion, for now you can keep using the widget, it should work without issues in v6 too.

Let me know if you have other suggestions.

Cheers