✨ add support for top level variables

[martinale14]

I created this pr to give support to top level variables for the scenarios where we have multiple urls and that urls depend on ambient. for example we have our service A to make the main requests but we have service B to specific funcionality with diferent base url and maybe we want to change the service B to a dev version, so to change the url we have tu rebuild the chopper files because base url points to the literal value of the variable, with this change we don't need to rebuild in that scenerio because we can point the base url to a top level variable and that variable is going to be present in the generated file instead of the literal value

Imaging this case

const String enviromentUrl = Enviroments.temporal;

class Enviroments {
  static const String temporal = 'https://api.example.app';
}

@ChopperApi(baseUrl: enviromentUrl)
abstract class TeacherDatasource extends ChopperService {
  @Get(path: '/get_teachers/start/open')
  Future<Response<List<TeacherModel>>> getTeachers();

  static TeacherDatasource create([ChopperClient? client]) =>
      _$TeacherDatasource(client);
}

Before the change:

final class _$TeacherDatasource extends TeacherDatasource {
  _$TeacherDatasource([ChopperClient? client]) {
    if (client == null) return;
    this.client = client;
  }

  @override
  final definitionType = TeacherDatasource;

  @override
  Future<Response<List<TeacherModel>>> getTeachers() {
    final Uri $url =
        Uri.parse('https://api.example.app/get_teachers/start/open');
    final Request $request = Request(
      'GET',
      $url,
      client.baseUrl,
    );
    return client.send<List<TeacherModel>, TeacherModel>($request);
  }
}

After the change:

final class _$TeacherDatasource extends TeacherDatasource {
  _$TeacherDatasource([ChopperClient? client]) {
    if (client == null) return;
    this.client = client;
  }

  @override
  final definitionType = TeacherDatasource;

  @override
  Future<Response<List<TeacherModel>>> getTeachers() {
    final Uri $url = Uri.parse('${enviromentUrl}/get_teachers/start/open');
    final Request $request = Request(
      'GET',
      $url,
      client.baseUrl,
    );
    return client.send<List<TeacherModel>, TeacherModel>($request);
  }
}

[techouse]

Can you please elaborate on the change?

[codecov]

Codecov Report

Merging #493 (da1c25b) into develop (c7b67a6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #493   +/-   ##
========================================
  Coverage    93.83%   93.83%           
========================================
  Files            9        9           
  Lines          454      454           
========================================
  Hits           426      426           
  Misses          28       28           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[martinale14]

Can you please elaborate on the change?

Thanks for the comment, I already edited the pr's comment

[techouse]

for example we have our service A to make the main requests but we have service B to specific funcionality with diferent base url and maybe we want to change the service B to a dev version, so to change the url we have tu rebuild the chopper files because base url points to the literal value of the variable

Maybe I don't fully understand, but to me this solution sounds like a hack and I'm not sure that it's the responsibility of Chopper to give the user the option of having multiple environments.

Why not simply abstract all these baseUrls into multiple environment files and load that baseUrl into the ChopperClient, i.e.

final ChopperClient client = ChopperClient(
  baseUrl: prodEnv.apiUrl // <--
  // ... stuff
);

Sorry if I'm being too nosy, but can you maybe provide a few examples?

[martinale14]

for example we have our service A to make the main requests but we have service B to specific funcionality with diferent base url and maybe we want to change the service B to a dev version, so to change the url we have tu rebuild the chopper files because base url points to the literal value of the variable

Maybe I don't fully understand, but to me this solution sounds like a hack and I'm not sure that it's the responsibility of Chopper to give the user the option of having multiple environments.

Why not simply abstract all these baseUrls into multiple environment files and load those based on the desired scenario?

Sorry if I'm being too nosy, but can you maybe provide a few examples?

i updated the comment again with an example, no problem bro

[techouse]

i updated the comment again with an example, no problem bro

I've cleaned it up for you :)

I see what you mean. I'd usually solve this using a ChopperClient instance, however, this seems like a viable solution as well.

Right, can you add some tests for this, then I think we can merge it :)

[martinale14]

i updated the comment again with an example, no problem bro

I've cleaned it up for you :)

I see what you mean. I'd usually solve this using a ChopperClient instance, however, this seems like a viable solution as well.

Right, can you add some tests for this, then I think we can merge it :)

ready man i upload some tests

[techouse]

LGTM

@JEuler @Guldem your thoughts?

[Guldem]

I don't think this addition doesn't do any harm. It doesn't directly change the way how some one would use chopper. Maybe a bit more documentation could be added in the doc files. So its not really a "hidden" feature.

Although I think I would have solved this by rewriting baseUrl in a Interceptor. If I had to change thinks runtime.