Swap slots in Azure devops (angular+api), how to change Angular configuration for the target slot?

The configuration of the Angular app is the challenging part. During our publishing Job in Azure Yaml pipeline, we execute a "token" replacement to match the target environment on this configuration on a tokenized-artifact.

Later we deploy this tokenized-artifact (tokens already replaced) to the especific environment:

    - task: AzureWebApp@1
      inputs:
        azureSubscription: 'xxxx'
        appType: 'webApp'
        appName: [depends on $(environment)]
        package: '$(Pipeline.Workspace)/xxx'

This way, we can have specific configuration for DEV, TEST, and STAGING (staging is a Production slot).

At some point, we need to swap STAGING to PROD. As result, we have the Angular app in PROD but with values are still for STAGING, which is incorrect, and here we are stuck on what to do. I would like to get advice on a good way to continue.

Some ideas:

• During the STAGING deployment, generate also the PROD files, using different name (i.e. main.*.js.PROD). Then, after PROD swap, rename the files, but..

  • The files may be in use and, therefore, cannot be renamed.
  • During rename a little downtime is added (I am not even sure if there is a way, for yaml, to rename the already deployed files).

• When deploy to PROD is triggered, first deploy to STAGING with PROD variables, then execute the swap, but...

  • It will have a longer deployment time, because STAGING will have to be deployed first, even if it is already deployed.
  • It is taking little advantage of slots.
  • PROD variables will remain in STAGING after swap.

• Do not swap from STAGING and do a complete deployment to PROD, but...

  • It will have the longest deployment time.
  • It will not take any advantage of slots.

Edit: Thanks to @prawin advice, I'll add another one:

• Provide configuration dinamically, from the server side
  • Looks promising since the frontend shares a host with the server side. But still, what in the case of being decoupled from the backend part? This means that the backend url will also need to be configured somewhere, by environment.

After some reading, trial and error, I have some more:

• Deploy only the changing file using FTP or Kudu API

• Generate and copy PROD config to STAGING, then perform the swap task. I really like this option the most.

Is there anything else to consider? What is the "standard" way to perform this?