Outdated documentation on IFrame API 2022

It is happening to me that with some functionalities that do not work and, apparently, they are deprecated seeing that in the reference file interface_config.js (https://github.com/jitsi/jitsi-meet/blob/master/interface_config.js ) I see the message “This file is considered deprecated. All options will eventually be moved to config.js, and no new options should be added here.”

Perfect, I’m going to see the config.js file (https://github.com/jitsi/jitsi-meet/blob/master/config.js), but I see that the configuration no longer starts or has the structure that marks the Handbook from const domain , const options, etc… (IFrame API · Jitsi Meet Handbook) instead in the new config.js it starts with

var config = {
    // Connection
    //

    hosts: {
        // XMPPdomain.
        domain: 'jitsi-meet.example.com',
...

Furthermore, the Handbook goes on to say that “You can override options set in the config.js file and the interface_config.js file using the configOverwrite and interfaceConfigOverwrite objects, respectively.”

But, the interface_config.js wasn’t deprecated?

I would like to please shed some light on this confusion and if you can update or post the new way to implement the IFrame settings since I work with external js.

Thanks.

deprecated means exactly what you read :slight_smile: . It differs from ‘obssolete’, it’s rather ‘will be obsolete at some point in the future’. it’s still used in 2022.

I would like to reprogram all the functions but I don’t have updated documentation on how to implement them.
Can you provide this information?

I think, you are mixing things. The iframe API is updated. The only connection between iframeAPI and config.js is configOverwrite param, where you can (overwrite some config params)[https://github.com/jitsi/jitsi-meet/blob/15cc956ed4f5f84e0d0c3e546c7c745291b29768/react/features/base/config/configWhitelist.js#L12]

I understand what you are saying, but what is not clear to me is because in the Handbook it tells me that the configuration has to start with (look at the “domain” declaration)

const domain = 'meet.jit.si';
const options = {

and in the config.js it starts in another way.

var config = {
    // Connection
    //

    hosts: {
        // XMPPdomain.
        domain: 'jitsi-meet.example.com',
...

I no longer have to use const domain?
I no longer have to use const options?
I no longer have to use const api?

It is what does not end up being clear, at least in my case.

If you could make this clear I would appreciate it.

config.js is what the frontend reads to connect to the meeting. When you use the IFrame API you only need to specify the domain, because then we can get the config.js ourselves from https://DOMAIN/config.js

You can then use configOverride to change the default behavior (what’s on config.js) with your chosen values.

All this I understand and I have it working.
What I would need is an example of use (as there is in the Handbook) but with the new way of using config.js to be able to start adapting everything since I have several projects that I must normalize

If you are using the iframe API you don’t use config.js.

If an option interface_config.js got deprecated it means you must use configOverride with the new option name instead of using interfaceConfigOverride with the previous name.

ooook! Now I understand.
I really have to keep using initialization as the Handbook

const domain = 'meet.jit.si';
const options = {
...
...

but if an option I had in interfaceConfigOverwrite I must remove it from there and place it with the new name in configOverwrite. Certain?

But always initializing with const domain =, const option = and const api = calling domain and option. Is that so?

Until now I was doing this but seeing that the config.js had changed certain things I thought I should also modify the initializations and previous calls.

But if I really only have to eliminate the old ones and put in the new ones, then it’s like until now. no?

Correct. Make sure you check the name of the option, we don’t always move them with the same name.

How you call your variables is not important here.

Correct. Note that we do leave ample backwards compatibility time. So if you set something in interfaceConfigOverride it won’t stop working overnight.

Cool!
Thank you very much for the clarification.