ocpp-rpc icon indicating copy to clipboard operation
ocpp-rpc copied to clipboard

WIP: Add Typescript types

Open alex1290 opened this issue 3 years ago • 11 comments

This is still a draft.

Hi Do you have the plan to add the Typescript types? I hope this library can be used in Typescript withourt adding additional type declaretion by user.

Please advise.

alex1290 avatar Jun 06 '22 07:06 alex1290

Hi alex,

This is something I would be interested in adding.

I will review this at my next opportunity. Thanks.

mikuso avatar Jun 07 '22 13:06 mikuso

Hi @mikuso , @alex1290 . Is there an update on this?

dannysood avatar Sep 05 '22 01:09 dannysood

To be honest I'm not a typescript developer and I don't feel comfortable incorporating this until I feel confident that I can support it long-term; I wouldn't want to bring in type definitions for a single release and then have them become incorrect in later releases due to neglect. Additionally, I don't know how to test these type definitions for completeness or correctness.

While I would love to natively support typescript types, it presents a challenge that I'm not quite ready for right now. One option might be for me to rewrite the whole module in TS for a 2.0.0 release.

In the meantime, if someone wants to take on the task of writing and maintaining the typescript types until then, it would probably be best to contribute these to the DefinitelyTyped project instead.

You may also have luck in making a request for this on their requests boards.

mikuso avatar Sep 09 '22 08:09 mikuso

@alex1290 Did you try to push it into DefinitelyTyped?

liketurbo avatar Feb 03 '23 16:02 liketurbo

To be honest I'm not a typescript developer and I don't feel comfortable incorporating this until I feel confident that I can support it long-term; I wouldn't want to bring in type definitions for a single release and then have them become incorrect in later releases due to neglect. Additionally, I don't know how to test these type definitions for completeness or correctness.

While I would love to natively support typescript types, it presents a challenge that I'm not quite ready for right now. One option might be for me to rewrite the whole module in TS for a 2.0.0 release.

In the meantime, if someone wants to take on the task of writing and maintaining the typescript types until then, it would probably be best to contribute these to the DefinitelyTyped project instead.

You may also have luck in making a request for this on their requests boards.

I can help with whole rewrite into TS

liketurbo avatar Feb 03 '23 16:02 liketurbo

To be honest I'm not a typescript developer and I don't feel comfortable incorporating this until I feel confident that I can support it long-term; I wouldn't want to bring in type definitions for a single release and then have them become incorrect in later releases due to neglect. Additionally, I don't know how to test these type definitions for completeness or correctness. While I would love to natively support typescript types, it presents a challenge that I'm not quite ready for right now. One option might be for me to rewrite the whole module in TS for a 2.0.0 release. In the meantime, if someone wants to take on the task of writing and maintaining the typescript types until then, it would probably be best to contribute these to the DefinitelyTyped project instead. You may also have luck in making a request for this on their requests boards.

I can help with whole rewrite into TS

If you provide contribution info

liketurbo avatar Feb 03 '23 16:02 liketurbo

@alex1290 Did you try to push it into DefinitelyTyped?

No. I do not have enough time to complete it after that. I would be grateful if you can complete it and push it into DefinitelyTyped

@mikuso Got it. Some fuction I didn't use in my project, so I don't have confidenice to define the whole type. I'm looking foward 2.0.0 releases. Thanks!

alex1290 avatar Feb 14 '23 06:02 alex1290

@mikuso any chance of reconsidering moving to TypeScript or at least have some basic support? Your library is probably the best in its category but it just misses such an important feature which makes dev's life much easier.

ease avatar Oct 26 '23 08:10 ease

Hi @ease

Thanks for the kind words.

I believe that the most important TS feature people are looking for with this library is to get some assurances that they have structured their OCPP payloads correctly, ensuring that calls are valid, and making it easier to handle the responses. Strict mode already ensures that the calls and responses will be valid for the protocol you're using, but you'd be right to say that it would be even better if it connected the dots to allow for compile-time checking too.

I did make some significant headway on a port to typescript (see the types branch), but I wasn't really satisfied with the way it was going...

I think that the main difficulty I'm facing with a typescript version is that the current API (specifically the call and handle methods) were not really written with typescript in mind from the start, and it requires some significant typescript acrobatics to let the compiler know which protocol you are using in order to provide the correct feedback to the developer at compile-time. For example, the RPCClient can potentially "change shape" depending on which server it connects to, thanks to its ability to dynamically agree a protocol with the server at runtime. Similarly, the RPCServer's client event can't easily communicate to the event listener what "shape" of RPCClient they're being given, as at compile-time we can only be sure that it's one of the protocols provided in the server constructor - if any. One (ugly) solution might be to emit different events for different clients - although this only solves half the problem. A better solution might be to provide a full paint-by-numbers framework where the developer only needs to implement the methods for all their supported protocols and then can ignore client handling altogether - but this would be a significant change.

Unfortunately, the whole idea of strict mode and validation came as an afterthought, as I had originally intended for this module to also be used for other non-OCPP purposes; I didn't want the module to necessarily be aware of which protocol it was talking, so none of this really crossed my mind at the time when I created it. Ultimately, the module's structure lacks a lot of the formalities that you'd expect from a library that ought to be more aware of its most common use-case.

I think that a proper (useful) TS re-write would require making some significant changes to the API to make it more TS-friendly, but I'm struggling to justify the time commitment to do this at the moment.

mikuso avatar Oct 26 '23 09:10 mikuso

I started an alternative approach to this - https://github.com/mikuso/ocpp-rpc/pull/68 feel free to close my PR if you want to return to this work in the future - @mikuso

pschoffer avatar Dec 19 '23 08:12 pschoffer

I have a basically complete index.d.ts file (including all the required acrobatics).

I'm happy to try putting it in to DefinatelyTyped, but we could also look at simply including it in the lib, if anyone is interested?

See here: https://github.com/mikuso/ocpp-rpc/pull/70

madpilot avatar Feb 12 '24 07:02 madpilot