Add project_id property to client to set it once and skip this parameter in functions

[xabk]

Hello!

I feel like most of the time, the client is used to work with one project but it still requires you to pass project_id into every single project-related function.

It would be great if the client itself had a project_id property that could be set and used by the functions under the hood.

What do you guys think?

[andrii-bodnar]

Hi @xabk, it's a nice suggestion but it feels like not a good pattern since there are a lot of other API methods where the project parameter is missing and it can lead to some confusion if it'll be globally available.

In addition, there are a bunch of other "common" properties for some groups of API methods. For example, stringId, screenshotId, fileId, etc. These properties also can be candidates for global configuration but it'll bring a lot of config options.

[xabk]

For me, project is the top-most thing in the hierarchy and it never changes within one code file/task, while other scopes like strings, screenshots, etc. can and do change as they're processed. So it makes sense to have this for project_id but not for smaller scopes.

I understand your concern though. And I have no idea if my workflows where project doesn't change from the moment I create the client are all that typical :)

[andrii-bodnar]

That makes sense, most likely project is not changing so frequently

[andrii-bodnar]

Actually, I think we can do this for a project 🙂

We already have such a configuration in crowdin-api-client-ruby

[andrii-bodnar]

Contributions are welcome :)

[xabk]

I'd love to help but this seems like too big of a scope of changes for an amateur developer like me. I'm not joking, I don't really know how to make sure the change is consistent and also compatible with the previous versions. E.g., there are cases where project_id is followed by another mandatory parameter. Not sure how to deal with those. I also have no experience with tests :(

Maybe if you'd start in a public fork/branch, then I could chip in with simpler, more narrowly scoped fixes that mimic what you've already done.