Reputation: 1
I am using Inertia in a Laravel-React stack and have a page component that lets me write, edit, and delete blog posts and preview them as they would be styled on the site in real time.
I have a form that uses the State hook to update the value of its fields and display form data in a styled div on the right. I also have POST routes that direct to a controller which does some transforming and inserts/updates/deletes the site database with form data.
The top of the form, in React 17:
<div className="editor">
{props.id && <h3>Editing {props.title}</h3>}
<form onSubmit={(e) => {
e.preventDefault;
!props.id ? // are we editing an existing post?
Inertia.post('gutenberg.new') : // if no, then insert a new one
!delPost.bool ? // if yes, are we deleting it?
Inertia.post('gutenberg.update') : // if no, then update with this ID
Inertia.post('gutenberg.delete') // if yes, then delete with this ID
One of the controller's public methods, in this case, for the "edit" route. Sorry if there is too much information here. I am curious if it's forbidden to use this kind of logic in a controller when trying to do something like this, or if I am breaking something else inadvertently. In PHP using Laravel 9:
public function updatePost(Request $request) {
$postID = $request->input('id');
BlogPost::where('id', '=', $postID)->update([
'title' => $request->input('title'),
'slug' => $request->input('slug'),
'body' => $request->input('body'),
'image' => $request->input('image'),
'language' => $request->input('language'),
]);
/* Now, we pull the existing associative records for the post in
from the post tags table to compare them to the tags that were
sent to the backend. That way, I can edit the tags for each post
within the editor itself.
*/
$comparisonTags = PostTags::join('tags', 'tags.id', '=', 'post_tags.tag_id')
->where('post_tags.post_id', '=', $postID)
->get();
// Get the tags included in the request
$collectedTags = collect(json_decode($request->input('tags')));
foreach ($collectedTags as $index => $tag) {
// Add any totally new tags
Tags::upsert(['name' => $tag], ['id', 'name']);
/* "If the tags included in the update request contain something
that the post tags table doesn't for this post ID, then insert
them there." */
if (!$comparisonTags->contains('name', $tag)) {
$tagID = Tags::select('id')->where('name', '=', $tag)->get('id')->toArray();
$scalarTagID = strval($tagID[0]['id']);
PostTags::insert([
'post_id' => $postID,
'tag_id' => $scalarTagID,
]);
}
}
foreach ($comparisonTags as $id => $tag) {
/* "If the tags in the post tags table associated with the
updated post's ID contain something that the new tag list
does not, then remove those tags from the post tags table."
*/
if (!$collectedTags->contains($tag->name)) {
PostTags::where('tag_id', '=', $tag->id)->delete();
}
}
return Redirect::route('index');
// Inertia requests need Inertia responses
// country roads... take me home...
}
public function deletePost(Request $request) {
// pretty self-explanatory
$postID = $request->input('id');
BlogPost::where('id', '=', $postID)->delete();
PostTags::where('post_id', '=', $postID)->delete();
return Redirect::route('index');
}}
And the route in question:
Route::post('gutenberg/edit',
[Gutenberg::class, 'updatePost'])
->name('gutenberg.update');
The problem occurs when using the Inertia.post method to send form data to the controller for handling there. The issue does not show up when I use the normal HTML form-action-method approach, but I want to use Inertia's visit method so that I can use CSRF protection on the site.
Upon submitting the form, rather than redirect to the Inertia response that the controller returns for its POST method functions, the page just dumps all of the form data into the query string. Nothing happens on the backend, as no updates are made to the database, and the old form data is still visible on the page.
A screenshot of my browser after hitting "Submit." Note the query string, with a title attribute of "a very different title" from the originally exasperated ffs.
Could the controller be introducing some kind of unexpected JSON response, thus breaking the Inertia.post method? I stepped through the whole thing with Firefox's debugger, and the only thing I saw that looked out of the ordinary was a terrifying 16,000-character wide line that included that string about each Inertia request needing a valid Inertia response.
Any help would be appreciated.
Upvotes: 0
Views: 1872