form helper data response without redirect

[dillingham]

How do you submit a form using the awesome helper and not redirect?
I want to return the newly created model and pass it as a prop to a different component after.
I know I can use axios but It breaks continuity and seems like how I would assume the form helper to work

Here is a quick example to demonstrate using vue to achieve this

https://twitter.com/Philo01/status/1373646016189173765

TLDR: #568 (reply in thread)

<modal>
    <div v-show="creatingPost">
        <create-post-form :author="author" @newAuthor="showAuthorForm">
    </div>
    <div v-if="creatingAuthor">
        <create-author-form  @success="updateAuthor" />
    </div>
</modal>

data() {
    return {
        creatingAuthor: false,
        creatingPost: false,
        author: null
    }
},

methods: {
    showAuthorForm() {
        this.creatingAuthor = true; 
        this.creatingPost = false;
    },
    updateAuthor(author) {
         this.author = author; 
         this.creatingAuthor = false; 
         this.creatingPost = true;   
    }
}

this.form.post(route('authors.store'), {
    errorBag: 'createAuthor',
    onSuccess: (data) => {
        this.$emit('success', data);
    }
}

Would be cool if when onSuccess is defined, it doesn't redirect.

Ideally, onSuccess would receive data from Controller@store

[dillingham]

Maybe a wantsJson parameter to explicitly request this behavior?

this.form.post(route('posts.store'), {
    errorBag: 'createPost',
    wantsJson: true,
    onSuccess: (data) => {
        this.$emit('success', data);
    }
});

And then in the controller you can return json if it wants it:

if(request()->wantsJson()) {
   return $post;
}

return Inertia::render()

This would allow the same form to work as a page and modal

[dillingham]

Better if Inertia\Response @ toResponse detected wantsJson automatically

So avoids an if statement in controller and just uses Inertia::render():

return Inertia::render('Posts/Index', [
     'posts  => $posts 
]);

...

if ($request->wantsJson()) {
    return new JsonResponse($this->props);
}

if ($request->header('X-Inertia')) {
    ...
}

So if the form helper sets a header of 'Content-Type': 'application/json', it just works ™️

this.form.post(route('posts.store'), {
    errorBag: 'createPost',
    wantsJson: true,
    onSuccess: (data) => {
        this.$emit('success', data);
    }
});

[dillingham]

@claudiodekker what do you think? I think JSON API support is kind of expected and essential to a SPA and better than throwing an error where developer experience is concerned.

All Inertia requests must receive a valid Inertia response, however, a plain JSON response was received.

[dillingham]

cant even redirect back from the ajax endpoint because its the same component
Major paper cut for me

[dillingham]

Another example of when you'd want to return data from $inertia.form

<app-layout>

    <comment-list :comments="comments" />

    <create-comment-form @success="comments.push($event)" />

</app-layout>

this.form.post(route('comments.store'), {
    errorBag: 'createComment',
    wantsJson: true,
    onSuccess: (data) => {
        this.$emit('success', data);
    }
});

[ajnsn]

This would be something for the upcoming dialogs feature.

Until the feature is ready, you could already Inertia::render back the original Posts/Indexcomponent and use the only attribute to partial load only e.g. an createdComment when posting a new comment.

Then watch this prop in your parent component to update/push to your existing comments data or even return the whole commnents - depending on how much comments data you have.

Hope this helps !

[ayoub-bousetta]

The best way in this case is the use Axios

[dillingham]

I'm using it now and I disagree, the best option would be to support json and the other features of the request helper

[ayoub-bousetta]

maybe but even the creator recommended a normal fetch or axios,

[dillingham]

Because it's complicated to support this request.. not because it's better

[devinfd]

I have a use case for this behavior. Passing a wantsJson: true in the request and letting Inertia intelligently handing that would be great!

[erfling]

Plus several 1s.

Inertia is great for 99.9% of our use cases. It's a lovely library and really simplifies the way we think about auth and routing.

That said, I'd love to be able to return plain JSON responses sometimes. We've got a couple of long running processes, like video encodes server-side, and Laravel doesn't make it very easy to queue Storage (for upload to S3 or similar). I'd love to be able to handle the response without a redirect if a user has navigated to another part of our app by the time an encode is done.

[mohitmamoria]

I made this quick wrapper around useForm helper to make API/JSON Calls:

https://gist.github.com/mohitmamoria/91da6f30d9610b211248225c9e52bebe

[aarondfrancis]

I too would love to be able to submit a form and get JSON back without having to jump through a bunch of hoops.

[reinink]

So while I get why this is wanted, and maybe we can figure out a solution that makes sense, but my gut reaction to this is that it goes against some of the core architectural principles of Inertia.

Architecturally Inertia isn't an alternative to XHR (Axios) or fetch, which are typically design for asynchronous requests. Rather Inertia is designed to mimic classic full page reloads that you find in server-side rendered applications.

Inertia request are synchronous — only one can happen at a time. This is just like standard browser visits. When you click a link, you go to another page. Only one visit can happen at a time. If you click another link while the first visiting is still loading, the first one is cancelled and the second visit takes its place. Plus each request results in a "full page response"...you've landed on another page in the application. This is pretty core to how Inertia works.

So, looking at @dillingham's example, I can see why this is a tricky problem to solve. There are two forms on the page — one to create a new post, and one to create a new user, which presumably once a new user is created you want that person to be selected as the user for the new post.

If you think about how you'd build that using classic full page form submissions, it gives you some ideas of how you can do that with Inertia:

• Submit form to create new user
• Validate and create the new user, and then redirect back to the create post page
• In the redirect back, flash the session with the new user id
• In the create post controller, check for the new user id in the session, and pass it through as a prop to the create post page component (maybe call it new_user_id or something like that)
• Have a watcher in the create post page to check if the new_user_id prop changes (from null to something`) and automatically select that user in the create post form
• Plus, your available users (presumably passed through asa prop) will automatically update to include the new user, since props are reactive

I actually recently created a shortcut for this in one of my apps, which I called Inertia::flash() (using a macro), which allows me to easily pass flash data from the server to the very next page component that's loaded. It works something like this:

<?php

class UsersController
{
    public function store()
    {
        $input = Request::validate([/* ... */]);

        $user = User::create($input);

        Inertia::flash(['new_user_id' => $user->id]);

        return Redirect::back();
    }
}

Now when a new user is created, the new_user_id is automatically available as a prop in my page component — these values automatically get sent as props to the next page component that's loaded — which you can create a watcher to detect, and update your form accordingly.

This honestly works awesome, but it feels pretty opinionated, so I'm not sure if it makes sense to bake into the Laravel adapter yet. It's super trivial to implement in your own apps though.

First create the macro:

use Inertia\ResponseFactory;
use Illuminate\Support\Facades\Session;

ResponseFactory::macro('flash', function ($data) {
    Session::flash('inertia', $data);
});

Next, update the HandleInertiaRequests middleware to automatically include these values in your payload:

  public function share(Request $request): array
  {
-     return array_merge(parent::share($request), [
+     return array_merge(parent::share($request), $request->session()->get('inertia', []), [
          //

Here's an example watcher in Vue.js for how to watch a "flashed prop" like this:

(this is sudo code)

const props = defineProps({
  users: Array,
  new_user_id: Number,
})

const createPostForm = useForm({
  title: '',
  user_id: null,
  body: '',
})

watch(
  () => props.new_user_id,
  (userId) => {
    createPostForm.user_id = userId
  },
)

I hope that helps explain why Inertia is built the way it is, and gives you some ideas of how to work through this particular problem.

I'm not opposed to other solutions, but I think one of the awesome things about Inertia — and one of the things that makes it so simple — is how every Inertia request results in a standard full page Inertia response, and I legit worry what it might do to the project to make it behave more like XHR or fetch.

And I know ya'll know this, but it's 100% okay to just use XHR or fetch sometimes in an Inertia app. These are not mutually exclusive. In my apps 99% of my requests are done using Inertia, but there are certain situations, such as polling, where the synchronous nature of Inertia doesn't make sense and I'll reach for XHR instead.

[aarondfrancis]

Thanks for the quick reply @reinink! I totally get your hesitation to expand the scope on this particular issue.

I think the thing I'm looking for here is the ability to use the form helper and all its niceties but skip the Inertia routing layer, if required. I can totally eject and use XHR or fetch, but then I'd have to rebuild all the error handling, busy state, etc.

I ended up going with a modified version of this (#568 (comment)) solution. It's a bit fragile because it recreates some of the internal form stuff, but at least it's consistent now.

I have a Connections model. I'm trying to let the user test the connection and save the connection, so I ended up with a /test endpoint that is API only using this new form method, and then the regular Inertia method to save the model.

// Test the connection
this.form.post('/connections/test', {
    api: true,
});

// Store the connection
this.form.post('/connections');

Both use the form, both get the loading states, errors, etc. I'd love if there were a way to do this natively!

[reinink]

Hey I messed around with how I might solve this problem with Inertia. Here are two possible solutions (I used our Vue 3 playground for this):

• Using a different endpoint and flash data
  • routes
  • form
  • diff
• Using the same endpoint form validation
  • routes
  • form
  • diff

demo.mov

Note, my fake validation is random, which is why it sometimes passes and sometimes doesn't.

Hope that helps Aaron! 🤙

[aarondfrancis]

@reinink I've been thinking about this some more and this line is the line that stuck out to me from your response:

Inertia request are synchronous — only one can happen at a time.

I agree with that, but I don't want this particular request to be an Inertia request! But I do want to use the form helper. I think you could give us an escape hatch by making the submit method editable from the outside:

https://github.com/inertiajs/inertia/blob/master/packages/vue3/src/useForm.ts#L202-L206

Even changing router to this.router would give me a chance to overwrite it and do my own thing for an API call vs Inertia call. Just a thought!

[dillingham]

@reinink can you think of any way my laravel app can work around this for a form where I want CompanyController@store to handle /companies/new form and the same form component nested in a page in other parts of the app? I want it to handle both scenarios. Creating a company from the companies index page and creating a new company within a modal or nested within a listing form for example is a pretty common scenario.

I feel like you could open up a header "wants-json" pretty easily and allow onSuccess to just get the data if it doesn't detect a redirect.. I have hit this so many times.. I will pay $500 for this

[dillingham]

cc @jessarcher bounty 👆 😅

[mohitmamoria]

You are right, Aaron. The router is the single piece that makes it difficult to make the API/JSON calls. If we replace it while still wanting the busy states, error states etc, you’ll realize that we will have to change the “options” parameter and rewrite it for axios/fetch. My gist earlier in above comments does the bare minimum stuff to get the form helper working with API/JSON calls.

On Wed, 5 Jul 2023 at 5:42 PM, Aaron Francis ***@***.***> wrote: @reinink <https://github.com/reinink> I've been thinking about this some more and this line is the line that stuck out to me from your response: Inertia request are synchronous — only one can happen at a time. I agree with that, but I don't want this particular request to be an Inertia request! But I *do* want to use the form helper. I think you could give us an escape hatch by making the submit method editable from the outside: https://github.com/inertiajs/inertia/blob/master/packages/vue3/src/useForm.ts#L202-L206 Even changing router to this.router would give me a chance to overwrite it and do my own thing for an API call vs Inertia call. Just a thought! — Reply to this email directly, view it on GitHub <#568 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVBAVVWSNQ343A6VT7KYDLXOVK4PANCNFSM4ZUHYZRA> . You are receiving this because you commented.Message ID: ***@***.***>

-- – mohit

[chuoke]

Hi, Is there any new progress?
I want that feature, too, and even more.
In my case, there is a form submission save feature that will appear in a variety of situations, some requiring a jump, but some not. I know it's against the rules, but it's the reality.

In fact, what we want is not to redirect, regardless of what the response is, right?

I tried an implementation that simply added a parameter that did not visit the page, that is, did not redirect. For more detail can see my fork submission. But this makes the core code look distorted. Hopefully, it will lead to a perfect way of doing it.
chuoke@286c7db
Focus on the packages/core/src/router.ts file.

[TimRoenicke]

@aarondfrancis - I've been back and forth the last few days wondering if I'm overlooking something obvious and I agree with this.

I think the thing I'm looking for here is the ability to use the form helper and all its niceties but skip the Inertia routing layer, if required. I can totally eject and use XHR or fetch, but then I'd have to rebuild all the error handling, busy state, etc.

I'm having to do context updates to the form (based on fields the user is filling out as they go along) and having to hop out of the form helper felt like i was doing something wrong, because of the fact we already have state there. It feels like inertia wants you to either subdivide your form into different page stages (different components / different routes - which isn't ideal for the forms i'm working on) or manage a "primary" formHelper and context-updating xhr calls that have their own "form helper" functionality rolled by you on a case by case. Which, may just be how it has to be. Anecdotally, looking through posts about passing data in inertia it seems like this is where a few people get hung up. As @reinink stated, we know we can reach for xhr but I think these paper cuts make it feel like you shouldn't be? When you should?

Just felt like I was duplicating functionality and adding complexity when it felt like i should just be able to say "Hey, formHelper, do a "basic" request because I don't want you thinking you need to do any page routing here."

Appreciate the detailed explanations @reinink! Thanks for all you do.

[ClaraLeigh]

I really didn't want to re-invent the wheel here, so I did a dirty hack using laravel precognition as I use that in all my other places anyway.

For my use case, I basically wanted a message to save incase you refreshed the page or went away and came back.
So, I hijacked precognition to do it:

public function withValidator($validator)
    {
        $validator->after(function ($validator) {
            if ($this->isPrecognitive()) {
                (new ExampleController())($this);
            }
        });
    }
    
    // Therefore I can save using form.validate('message'); 

IMHO, this would be an amazing feature to be built in, not because its truely needed but it keeps the code for all forms the same, even when you aren't needing redirects.

However, I honestly wouldn't mind if there was another package like the laravel precognition one that has essentially the same api to keep things simple. Not having to mess with axios and do error handling / validation is a real time saver

[UltraWelfare]

I don't have exactly the same issue as wanting the response as JSON but I figured I'd also share my own story since I also kinda need to use the form-helper without the redirection part:
My use-case is a single route (an index) which contains a table with pagination, filters etc.

Each row on this table has an "Edit" button which opens up a modal to do any changes you want, click save and close the modal.

The way I do this is using an editId query parameter. Basically on the controller level:

public function index(Request $request)
{
    return Inertia::render('Customer/Index', [
        'customers' => fn () => /* ... query with filters and pagination */,
        'editCustomer' => fn () => isset($request->query('editId')) ? $queryCustomer->get($request->query('editId')) : null,
    ]);
}

My react Index component looks like this:

export default function Page({
                                 customers,
                                 editCustomer
                             }: {
    customers: PaginatedCollection<PaginationCustomerData>
    editCustomer: CustomerData | null
}) {

  return <AuthenticatedLayout>
        <DataTable data={customers}/>
        <EditCustomerDialog customer={editCustomer}/>
    </AuthenticatedLayout>
}

The edit button is inside the DataTable component but in generally looks like this:

<Button onClick={() => {
    router.reload({
        only: ['editCustomer'],
        data: {
            editId: customer.id
        }
    })
}}>Edit</Button>

So when clicked, it will make a visit to the same index page with the query param, allowing a fetch to be made.
Then inside the EditCustomerDialog, it sets the form:

export default function EditCustomerDialog({
                                                 customer
                                             }: {
    customer: CustomerData | null
}) {
    const {data, setData, errors, put, reset, setDefaults} = useForm({
        name: "",
        email: ""
    });

    useEffect(() => {
        if (customer) {
            setData({
                name: customer.name,
                email: customer.email || "",
                points: customer.points.toString()
            })
        }
    }, [customer]);

     // .. other code ..

    return <Dialog open={customer !== null} .......

The problem arises when doing the submit

const onCreateSubmit = (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    put(route("customers.update", customer?.id), {
        preserveScroll: true,
        onSuccess: () => {
            router.visit("", {
                replace: true,
                preserveState: true,
                data: {editId: undefined}
            });
        }
    });
}

The problem with this is that it will do a double-fetch/navigation. Once the put is done successfully, it will try to redirect to whatever the controller says (I have a return back(); in the update endpoint method), which will do 1 request. Then afterwards the onSuccess router.visit will trigger to remove the editId parameter (to close the modal) which will be the second navigation...

Ideally, I would wanna ignore the redirect from the controller (even better: just return a 200 and not do a navigation) and handle the navigation on my own.

One solution would be to use axios, but then I lose all the useful stuff from the useForm helper.
Another solution is to somehow pass the current query parameters with the form data so I can grab them on the controller, strip out the editId param and redirect to index using the new query params (which will have the omitted editId omitted) but this seems kinda clunky :/

I'm not sure of any other solutions here, and it would be helpful to tell inertia "hey, it's okay I'll do it manually"

[UltraWelfare]

The ""best"" solution in my mind is currently this:

remove the router.visit from the onSuccess.

in the update method of the controller, get the previous url and strip off the query parameter:

$previousUrl = url()->previous();
$parsedUrl = parse_url($previousUrl);

$queryParams = [];
if (isset($parsedUrl['query'])) {
    parse_str($parsedUrl['query'], $queryParams);
    unset($queryParams['editId']);
}

$previousUrlWithoutEditId = $parsedUrl['path'] . (!empty($queryParams) ? '?' . http_build_query($queryParams) : '');

return redirect($previousUrlWithoutEditId);

it can probably be written way better, but it was quickly written as a proof of concept... This way is the best, it doesn't double fetch and inertia is doing is job with the navigation... The only thing remaining is to abstract this into a separate getPreviousUrl(array $withoutParams) so you can easily write return redirect(getPreviousUrl(withoutParams: ['editId'])); or even better return redirectToPreviousUrl(withoutParams: ['editId']);