Add the ability to mutate pageProps

[sebastiandedeyne]

Sometimes I wish there was a way to mutate the page props.

For example: you have a list of posts that have a publish button that uses Axios. After clicking publish, the post's status needs to be updated.

The current way of doing thigs:

1. Inertia sends a posts object in the response
2. You need to copy the posts object to local component state, which may be mutated
3. Whenever an Inertia.visit happens with preserveState, you need to manually override your local component state with the fresh posts data

This is really annoying to maintain, and would be simpler if we could just mutate the prop in Inertia.

This is a potentially dangerous feature, so I'm not sure about it yet. Would like some external input.

[reinink]

So, in your example, why wouldn't you just do an Inertia.put() to update the post status, and then redirect back to the post index? What's the benefit of doing this an an Axios request?

[sebastiandedeyne]

This probably doesn't matter in the posts example, however, if you're dealing with data that changes often, there's a chance that your list has completely changed by the time you do the put request.

If you're on page 2 of a list, modify an item, and receive a new set of data for page 2, there's a chance that the item you modified isn't part of the list anymore, which would be super confusing for the user.

We do this in Flare, since errors can come in pretty fast is an application is on fire. We use Axios call to resolving or snoozing errors to ensure the context doesn't completely change after a request.

[reinink]

Ahh yes, real interesting. That makes sense.

Something that needs to be considered here is that if we change the props somehow, we'll also need update the cached history state data as well.

I also wonder, with a feature like this, if you'll quickly get into modifying the URLs and history state as well. I feel like this is a dangerous road to go down, but will be very tempting.

[reinink]

So, I'm seeing some interesting use cases for a feature like this, where you can modify the root level props (page object), which then reactively updates the page component props.

One really neat use case for this is infinite scrolling. Imagine you have a tweets page, that shows the 15 most recent tweets. Then, when you scroll and load additional tweets, you could use something like Inertia.updateProps() to push these additional tweets into the page object. Something like this:

loadMoreTweets() {
  fetch(`/tweets?page=${nextPage}`)
    .then(response => response.json())
    .then(tweets => Inertia.updateProps(props => {
      props.tweets.concat(tweets)
      return props
    }))
}

A different approach would be to allow per visit prop transformations:

loadMoreTweets() {
  let currentTweets = this.tweets
  Inertia.get(`/tweets?page=${nextPage}`, {
    transformProps(props => {
      props.tweets = currentTweets.concat(props.tweets)
      return props
    })
  })
}

I like this approach as well, for two reasons. One, you can still make these requests with Inertia, and second, transforming props is already a thing in Inertia. However, I suspect the Inertia.updateProps feature would support a wider range of use-cases.

[sebastiandedeyne]

In React-land there's a library called SWR that helps you deal with fetching/caching/invalidating data. SWR has a very interesting mutate function.

mutate allows you to modify data before sending a request. So you can optimistically update the UI before the request is fulfilled.

// update the local data immediately, but disable the revalidation
mutate('/api/user', { ...data, name: newName }, false)

// send a request to the API to update the source
await requestUpdateUsername(newName)

// trigger a revalidation (refetch) to make sure our local data is correct
mutate('/api/user')

I think there are some interesting ideas in there we could use as inspiration, including the name.

function updateUser(user) {
    Inertia.mutate(props => ({ ...props, user }));

    Inertia.post('/users/123', { user });
}

[martbock]

Sorry for opening up this old thread, but I have a use case where mutation of props would be great to have.
In my app, users can create idea cards that are sorted by the amount of votes they receive from other users. If a user clicks on the "vote" button of a card, I currently have to reload the whole idea list property – which is why the sorting of the cards will change. I think that it is pretty confusing for users when the card they are hovering suddenly switches with one of the surrounding ones.

[narasimhajupally]

I am facing this use case quite often.Right now I am cloning prop into data which can be mutated.
I also tried
this.$page.props.<propName> = updatedValue mutation is happening
but I am worrying if it causes any errors.
can someone give me info if it bad or is ok? Thanks

[MattPurland]

I have a situation where manually updating the page props would be ideal (I stupidly assumed it would be possible)

I'm using Laravel Echo to subscribe to a channel which broadcasts an event that returns the data I need to update the prop with. I could do an Inertia.reload() but that's not great for user experience and seems like overkill considering the event has already returned the data.

The prop itself is shared across all routes (via middleware) and is referenced in multiple places (I've put the channel registration in the shared layout).

Any thoughts would be welcome

[MattPurland]

I'm using Svelte and I'm unable to do this, I'm neither able to 'set' the props or update the store. This might be where I'm misunderstanding how stores (or the page store) it setup

[narasimhajupally]

ok sorry, what i said was in VUE

[MattPurland]

No problem!

I believe I've found a solution for Svelte, but I'm 99.9% sure it's not recommended:

import store from "@inertiajs/inertia-svelte/src/store";

let channel = window.Echo.channel('channel');

channel.listen('.EventClass', (e) =>{
    store.update(p => {
        p.page.props.prop = e;
        return p;
    });
});

The above works exactly as I'd hope, but I'm sure @reinink will tell me off!

[tarikhagustia]

i'm implementing same way using laravel echo, but in react any best practice to update props with new data from echo?

[kabelo2ka]

@tarikhagustia Same here, any best practice found?

[vinnygambiny]

Someone find a way to update the prop with a Laravel Echo data in VueJS?

[vinnygambiny]

I find a way and open a PR #1633

[Marwzoor]

I am also facing this issue and have solved it with a Pinia-store. The problem which occurred though is that I want the history state functionality that comes with Inertia. Even though I’m modifying my store or have a local variable in my component which I can mutate they will be overwritten if I watch the Inertia page-object for changes.

So I solved this by digging into the Inertia source code and actually modify the history state with the updated props. The problem that I got there was that Inertia replaces the state with it’s local page object when navigating to a new page to save the scroll position inside the state. So I figured the only way to alter the page object inside the Inertia class was to use the popstate listener which gets the page object from the state.

Here’s what I came up with:

import { usePage } from '@inertiajs/inertia-vue3';
import { defineStore } from 'pinia';
import { ref, watch } from 'vue';

export const useStore = defineStore('props', () => {
	const pageProps = usePage().props;

	const props = ref(structuredClone(pageProps.value));

	let inertiaRefresh = false;
	let propsRefresh = false;

	watch(
		() => pageProps.value,
		(newProps) => {
			if (inertiaRefresh) {
				inertiaRefresh = false;
				return;
			}

			propsRefresh = true;
			props.value = {
				...props.value,
				...newProps
			};
		}
	);

	watch(
		() => props.value,
		() => {
			if (propsRefresh) {
				propsRefresh = false;
				return;
			}

			// Get current state
			const currentState = structuredClone(window.history.state);

			const stateData = {
				...currentState,
				props: structuredClone(props.value)
			};

			// Update state
			window.history.replaceState(
				stateData,
				'',
				currentState.url
			);
			// Push the same state to the history stack
			window.history.pushState(
				stateData,
				'',
				currentState.url
			);
			// Refresh Inertia, this will trigger an update to the page props
			inertiaRefresh = true;
			window.history.back();
		},
		{
			deep: true
		}
	);

	return {
		props
	};
});

It’s a dirty solution but it works😄 it’s handy when I need to do requests without the Inertia methods or update props using Laravel Echo.

Would be lovely if this could be done in a more official way with methods inside Inertia. The PR that @vinnygambiny created gets a +1 from me!

Update: This worked for updating the page props but caused some issues with the scrollposition being changed. So I’m doing a fork of Inertia which is able to mutate the page props.

[aljabr]

Hi,

Any Update on this?

I have a situation where i need to push the url state without the need to make any server side visit
the issue when i use pushState it will broke the history.

[webdevnerdstuff]

I'm not sure if this is the best idea (please correct me if it is bad), but in Vue I noticed I could do something like the following snippet. It was to solve the issue of foos reverting back to it's original state when using the mouse back button/back button. It would be good to know if this is an acceptable way to do things.

import { usePage } from '@inertiajs/vue3';
import axios from 'axios';

const $page = usePage();
const foos = ref($page.props.foos);

function saveFunction(item) {
  axios
    .put(route('foo.route'), {
      id: item.id,
    })
    .then((response) => {
      $page.props.foos = response.data.foos; 
    });
}

I do like it better than using popstate example someone posted here: #565 (comment). Even though the poptstate example does work, I don't quite like the slight delay that happens before it reloads the page.

[jesseschutt]

I've been building apps with Inertia for a few years now and I keep hitting the issue where I need to update page props with data passed through a Laravel broadcast event. Normally I use the lazy reload functionality and make a router.reload request. Although it works, it doesn't feel right. The data I need is already provided in the broadcast event but because there isn't a clean way to update the page props I have to reload the whole data set.

I understand the reason we don't normally mutate props but the alternative of reloading seems less than ideal. It would help me a lot if there was a way to do this.

[MattPurland]

I've been building apps with Inertia for a few years now and I keep hitting the issue where I need to update page props with data passed through a Laravel broadcast event. Normally I use the lazy reload functionality and make a router.reload request. Although it works, it doesn't feel right. The data I need is already provided in the broadcast event but because there isn't a clean way to update the page props I have to reload the whole data set.

I understand the reason we don't normally mutate props but the alternative of reloading seems less than ideal. It would help me a lot if there was a way to do this.

Note: use this method at your own risk

I got around this by patching the npm package (@inertia/svelte in my case) using patch-package - see below patch:

@inertiajs+svelte+1.0.15.patch

All this does is export the store used for the props, allowing me to import it wherever I wish to then update the props from a broadcast event:

        import { store } from "@inertiajs/svelte";

        Echo.channel('channel-name').listen(".UpdateProps", (e) => {
            store.update((p) => {
                for (const [key, value] of Object.entries(e)) {
                    p.page.props[key] = e[key];
                }

                return p;
            });
        });

I really should submit a PR, considering all it's doing is exposing the store so we can update it. Unfortunately I'm unsure if this can be done with Vue or React, but hopefully it'll give you an idea.

[reinink]

Hey @jesseschutt thanks for sharing this use case! I've shared this with the team and we're going to have a closer look at this 👍

[Fuzzyma]

@reinink I have the same issue. Laravel Echo is pretty much only usable as a "hey, pls reload. I got some new data" thing. But actually changing data is not really possible the way it is. Mutating the page props would help tremendously with that.
It could be as simple as making usePage return a writable computed instead or export a composable that returns the pageRef.

In app.ts

  return reactive({
    page: computed({
      get: () => page.value?.props,
      set: (newProps) => {
        page.value.props = newProps
        router.replaceState(page.value)
      }
    })
  })

[pascalbaljet]

@Fuzzyma You can do this with client-side visits in v2. Check out my video for this exact use case with Echo: https://www.youtube.com/watch?v=umcqTs1GEQY

[Fuzzyma]

@pascalbaljet that's just perfect. Thank you!

I even read the docs before but it didn't click for me that this is what I need 🙄

[Marwzoor]

I actually created a fork of inertia where I have solved this issue for anyone interested:
https://github.com/KrebitAB/inertia

This allows you to modify the page props without reloading.

Here are the NPM repos:
https://www.npmjs.com/package/@krebitab/inertia-core
https://www.npmjs.com/package/@krebitab/inertia-vue3