feat: $designer.id based URL

[yeze322]

Description

closes #4170

triggers[0].actions[1] -> triggers['475044'].actions['485963']

Task Item

Screenshots

[coveralls]

Coverage increased (+0.2%) to 55.591% when pulling e858318 on nav/designer-url into 1d272a8 on main.

[yeze322]

@cwhitten Chris where do you think we should append the setting option to? Or make it an extension?

[yeze322]

@lei9444 Leilei could you help checking if there is any missed case about the selected and focused url params?

[cwhitten]

@cwhitten Chris where do you think we should append the setting option to? Or make it an extension?

Can you clarify this a bit for me? I'm not sure what you are asking.

[yeze322]

@cwhitten let me rephrase that.
Do we plan to retire the array index formatted URL, or only use the $designer id URL in PVA env? (I thought it was the latter one.)

If we use $designer id URL in PVA meanwhile keep the array index URL in Composer, then we need an URL option to control which URL format to activate. So where do you suggest we put this URL option at?

I think it could be:

1. in Settings page, editable when running Composer
2. in node ENV, determined during build stage
3. make the URL encoder as an Extension, build PVA version without this encoder extension

[boydc2014]

@cwhitten let me rephrase that.
Do we plan to retire the array index formatted URL, or only use the $designer id URL in PVA env? (I thought it was the latter one.)

If we use $designer id URL in PVA meanwhile keep the array index URL in Composer, then we need an URL option to control which URL format to activate. So where do you suggest we put this URL option at?

I think it could be:

1. in Settings page, editable when running Composer
2. in node ENV, determined during build stage
3. make the URL encoder as an Extension, build PVA version without this encoder extension

Is there a way we support both format at the same time?

[cwhitten]

@cwhitten let me rephrase that.
Do we plan to retire the array index formatted URL, or only use the $designer id URL in PVA env? (I thought it was the latter one.)
If we use $designer id URL in PVA meanwhile keep the array index URL in Composer, then we need an URL option to control which URL format to activate. So where do you suggest we put this URL option at?
I think it could be:

1. in Settings page, editable when running Composer
2. in node ENV, determined during build stage
3. make the URL encoder as an Extension, build PVA version without this encoder extension

Is there a way we support both format at the same time?

@boydc2014 @yeze322 when we discussed last, we considered a routing layer that will transform an id-based url into an array based url and supporting both

[yeze322]

The tricky problem here is it's a bi-directional transformation. By supporting both of them, only one format will be activated at last.
The bi-directional transformation means the relationship between URL <-> resource location

• When parsing URL to resource location (inputting triggers[0].actions[1], focus on correct Action), it's easy to be compatible with both designerid based URL and array index based.
• However, when generating URL from currect location (e.g. clicking on a Trigger / Action), we have to choose a specifc format, and indeed the browser history will contain only one format.

[yeze322]

So I think that it's necessary to use a config to define which format is by default.

And at the same time, we can have a solution that inferring current URL format on Composer loaded and then stores it as a global state. This state will instruct which format to use when generating new URL from new resource location.

[cwhitten]

Hmm. Seems like we would want to avoid this if we can.

What if we changed the routing to only support id-based urls? How would we structure this if we didn't have the array-based constraint?

The more I think about array-based urls and what one expects of a url, it seems less correct. The simple scenario I get tripped up with is:

If I save a deep-link to my clipboard, and someone re-orders the element in the array, the index now points to an incorrect resource

The benefits of array-based don't seem to outweigh this seemingly fundamental problem.

[yeze322]

@cwhitten That's a reasonable and important scenario. We actually have no strong dependency with the array based URL, I agree with you. To achieve that, all changes required is just as this draft PR's changes.

[cwhitten]

Can we revisit the query string also? If we don’t support array-based, there is no need for [ or ] in the values

[boydc2014]

Note: The call we made at today's platform sync is keep this PR scoped to transforming the url from index based to id based, and without changing the basic pattern how url is composed.