Aceitar tipos customizados de serviços

[luizspinelli]

Aceitar tipos customizados de serviços oferecidos pelos correios a empresas parceiras

[Deividy]

Thanks for your submission! :)

But, this PR is only adding TypeScript declaration, the best we can do is map the services (if is possible), if it is not possible to map the services (e.g. correios accepts random service codes), we might need some tweaks here and a unit test for this.

[EduardoJM]

Now we have (in TypeScript) two overloads of the function, one accepts only the declared types and the other accepts any string value.

Is that:

Working (compiling TS to JS and running with node) in the two usage scenario (using mapped services and using custom):

[Deividy]

wow, there is a lot of services nowadays, makes me think if that dictionary of frete.servicos* is still useful, we may want to remove this in future 🤔

[Deividy]

I'm sorry, reverted. I miss understood the comments (my bad :$)

anyways...

the main idea here is; our module should accept any arbitrary code that correios might add in the future (what it already does), having a dictionary for type checking/easy access to these codes is very handy, but not necessary

so, to improve our TypeScript, we can use the interface suggested by @EduardoJM, which I liked!

export interface FreteOptions {
    //...
    servico: string;
    nCdServico: string;
// ...
export interface Frete extends FretePropertiesPrototype {
    servico(value: CodigosServico): Frete;
    servico(value: string): Frete;

and maybe get the response from listaServicos() and load this as a utility? is not that big and might be useful to easy/fast checking codes and find services

[Deividy]

Well.. since I caused some confusion here (merging/reverting), I decided to jump in with you guys! :)

I made some things;

• First, dumped the response of listaServicos to correios-data/listaServicos.json, also moved the CalcPrecoPrazo.xml to the same path

• Added a script (dump-services.js) that knows how to query correios and save the listaServicos.json, which is small (40.2kb and 332 services), also this script knows (in a very hacky way) how to read the frete.d.ts and update the definition :)

• And finally, I added a way to get these services in our frete.js, now we have a frete.servicos.list (with all services), and the frete.servicos.names{} with all names, bonus that we have a frete.servicos.search() to search services

the only drawback of this approach is that we now ship all these services with our module and we have to maintain the listaServicos.json, since it's small and it's all very handy, think it's fair enough.

what do you guys think?