Setting URL params now triggers reevaluation of `url` object — intentional breaking change?

💬 App Building
,
1

It looks like the behaviour of utils.setUrlParameters() / the "Set URL Parameters" event handler has changed, and it broke one of my apps.

Previously, calling this would only update the URL in the browser and the url object (url.searchParams, url.hashParams) would not reevaluate. See URL Parameters Not Reactive - #11 by Tess

Now it seems like setting URL params also triggers a reevaluation of the url object, meaning anything that references url.searchParams.myKey reacts to the change mid-session. My app relied on the old behaviour and this is now causing unintended side effects.

A few questions:

  1. Was this change intentional? and is it here to stay?
  2. If yes - is there a recommended way to write a URL param for deep-linking/shareability purposes without causing a reevaluation? This was actually a nice pattern before: the URL would reflect state without feeding back into the app.
1 Like
4

Thanks for posting about this, @TobiasOhlsson! I almost put out a proactive announcement about the exact change that you're referencing.

The fact that setUrlParameters didn't update the url object has long been considered a bug, but our Engineering team didn't quite anticipate the impact of fixing it. The primary fallout that I've seen is unintentionally re-triggering queries that read from the global url variable. Is that what you're seeing?

If so, you'll want to change the run behavior of said queries from Automatic to Manual and then specify a curated list of Watched inputs

image
image944×308 16.7 KB

Alternatively, you can leave the run behavior on Automatic and explicitly disable the query if the url object's values have changed since initial page load.

The current stance is that this new behavior is here to stay - and that we'll help individual customers with the correct implementation - but we're still estimating the scope of impact. I hope that helps! Let me know if you have any questions.

5

Thanks for the Reply. That change makes sense to me and I remember expecting this behavior in the past as well. The heads up would have been nice thought :smiley:

1 Like
6

Agreed! To be clear, though, I also wasn't aware of this until we started getting scattered customer feedback and connected it back to the relevant PR. That was when I considered posting to the Community. :sweat_smile:

7

A heads up would have been appreciated. This caused an infinite loop on one of our most-used apps which I just spent 45 minutes fixing with no mention of any change on your changelog/community. Extremely frustrating.

1 Like
8

I will make a point of doing this in the future! Thanks for the feedback. The bigger win - and something that I think is long overdue - would be a granular changelog for each cloud release. I'll keep you updated. :+1: