Best way to send flash message from javascript redirect

Firstly, you may consider to redirect from Laravel instead of your JS. If your use-case is not allowing that, then I see your solution as a good one.

Another solution - in case you don't want to send GET parameter - is to send AJAX request (to add the flash message to the session) and redirect when you receive the response.

thanks a lot for your input @andonovn .

Hm. That is interesting about adding the flash message to the session. I haven't worked with the session before (I'm new to laravel and web programming in general) but that does seem nice than sending it as a GET parameter since once I redirect with the GET parameter, then when I refresh the page, the GET parameter is still there, even though I don't want it to be at that point.

@jeloqim, check out:

1. https://laravel.com/docs/5.4/session#flash-data

2. https://github.com/laracasts/flash

@see_kay great! thanks

@jeloqim to be honest with you the AJAX solution is kind of "hacky" in my eyes, and I have never used it so far. It is adding an additional amount of effort (what if the ajax fails or even worse - if is delayed several seconds... you have to handle both). Also, you are unnecessary hitting your server, and the server-side code will look kind of "ugly".

Since you stated you are new to web programming in general, would you mind if you share your use-case - why would you want to redirect from the JS? I am asking because this may be avoided in most cases.

@andonovn Hm, I see. My use is case is having a link element which has the text "Delete" and if the user clicks on it, then javascript handles the click instead of a default link behavior and then I use AJAX/jquery Ajax to send a DELETE method to the server. Then a controller deletes the relevant eloquent model and I would like to flash a successful delete message.

For this use case (Deleting a model) it does make sense to me to avoid AJAX because maybe it less reliable than other methods (like a form submit?) but it is not unnecessarily hitting the server, because there is no way to delete without hitting the server at some point.

I guess I could create a form element and have a submit button which deletes, but is this the correct use case for a form? I figured I shouldn't be creating forms every time a user clicks on something which needs server side code. But I am very happy to hear what you/this forum has to say about it, since I am new.

@jeloqim Well, I didn't know that you are already sending an AJAX for the delete. So yeah, your solution is fine if that's your workflow:

1. Handle on click event and fire AJAX
2. On server: delete the model, flash message via the session
3. On client: on success -> redirect.

However, personally I would go with the many forms method instead of AJAX when my goal is to redirect in the end. I don't think there is a problem to have dozens of forms on the same page as long as they are not nested. Haven't thought about this to be honest. Please correct me if I am wrong.

And just one tip in case you don't know: instead of redirecting you may just delete the row from the html dom, thus leveraging the power of AJAX (saving the additional GET request and letting your user interact with the page while the server is loading). Another option would be your AJAX to return you the new results (after deleting the record) so you can directly replace the html for your table (or whatever format you are showing the results in).