Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

patpaskoch's avatar

Inertia and Data update

I am just curious how to handle data update with inertia.

Let's say I have to create-form on the same page as the data listed. After I created a new item, what would be the best way to update the data list, after a new item got added?

Greetings

0 likes
10 replies
ignaciodev's avatar
Level 2

Because of how Inertia works, simply using a return back() from you Controller after storing the new record, would cause the data list to be updated without refreshing the page.

public function index()
{
    $posts = auth()->user()->posts();

    // Render index page which also includes create form
    return Inertia::render('Posts/Index', [
        'posts' => $posts,
    ]);
}

public function store(Request $request)
{
    // Some validation

    $post = auth()->user()->posts()->create([
        // Whatever fields
    ]);

    return back(); // Back to index page. All this happens without refreshing
}
1 like
patpaskoch's avatar

I for sure should go more into the docs but I am just curious about the different approaches.

So return back() returns the data (post) created, or it just returns with the whole list? (if that makes any sense)?

Max100's avatar

Not sure it this is what you're asking, but if you're using the form helper, look at the options on form post.

Using the onSuccess , preserveState and only options, you can return only the data you need which can then be read as prop on success. In your controller, rather than using back(), you'd use inertia::render to call the same component and pass the data you want to receive.

1 like
patpaskoch's avatar

Thanks, I think that's sounds like, the way. Can you maybe point me the direction for the docs? I can't find the topic.

I worked till now with Vue-Router and Vuex.

How you would go about working with Broadcasting/Echo to update the data when working with Inertia?

I am just try to get everything hooked up in my mind before i start with the whole thing.

Thanks

Max100's avatar

Look at the docs on forms and the form helper: https://inertiajs.com/forms. Also, look at the visit options, including the part on partial reload, if that's something you want. https://inertiajs.com/manual-visits

I haven't used vue-router or vuex, so I'm not sure about broadcasting/echo to update the data. You can decide how to handle the new data after the add or update. You can refresh the entire component with all new data by calling it again after the add/update. Or you could use the preserveState option, and when you call the component, pass in the data you want and handle it in the onSuccess function.

If you're just looking to update the data list, it should refresh automatically when the component is called again with the updated data, with or without preserveState.

If you have any other questions, let me know and I'll try to help.

1 like
patpaskoch's avatar

@Max100 Thanks for the links, help me a ton. So I found the Event callbacks/Global Helpers to handle successful create or update requests. So I can decide if I want to just append the new item or reload the whole list, nice. What would make more sense?? or best practice?

Whats about Partial reloads, would that also be a nice way to go about getting the updated data list?

Max100's avatar

@patpaskoch I think it depends on the size of the list data. For a new item, you could write the js code to append the new data to the existing prop data.

But I prefer to have the database handle everything, so I reload the list after an addition/update. That way, everything is in the proper order without needing to write any additional code. Also, the refreshed data might include changes/additions made by other users in the interim.

If the list is long, you can use paginate to keep things quick and only pass the data needed for the component.

Regarding partial reloads, it can be really helpful in certain situations. For example, I have a page involving several tables where I send a bunch of data the first time the component is rendered. After that, when data is updated, I use 'only' to refresh just the updated table. The index function will know what data to send back, which makes things very efficient.

There's a good explanation of this here: https://inertiajs.com/partial-reloads And the screenshot at the end of the Lazy Data Evaluation section explains different options to determine when data would be sent or even evaluated.

I'm still finding my way, but Inertia is pretty slick.

patpaskoch's avatar

@Max100 thanks for your thoughts on that topic, yeah Inertia looks pretty promising for this topic. I will pick your brain again if I dive deeper into it.

Randy_Johnson's avatar

If you want it to be really quick, what I do is I have two lists, I have the db and a list in js. I pull the list from the db, and then store it in a js list. When I store an item to the database I just add that item to the front end list. That way there is no loading time, and the experience is more seamless.

patpaskoch's avatar

@Randy_Johnson Thanks Randy for your answer, That's what I did with Vuex exactly the same, so I had a Server-side Model/Controller and a Client-side version of it. It worked, but I don't like it. It just feels redundant creating an update, create, delete function once in PHP and once in JS. Maybe it's just me, but If I create a new Topic, I have to write it in JS and PHP twice. Don't know, I thought with Inertia there is a slick solving for it.

Would it be nice if we just load the data to the front end (js) and Internia takes care of keeping the data in the js and database in sync. So if we CRUD something from the DB it's automatically mirrored on the Client-side, without the hustle of always manually writing the js. for every single topic. Would it be nice???

And the same for the broadcasting updating the model and broadcasting should also update the js of the other users what it got broadcasted to. Because we mostly do the same every time. Wouldn't it be nice?

Please or to participate in this conversation.