Typescript migration?
Opened this issue · 21 comments
As I saw you recently added some @type jscomments. There are quite a few "objects" around and figuring out what properties exist on each of them takes (i my opinion) unnecessary amount of time and is prune to undefined errors.
@DutchmanNL . I don't know if you're familiar with Typescript. Would you be open to a typescript migration of this adapter (if I do a PR)?
PS: Typescript is a superset of js, so just adding / using plain javascript is still an option then (although of course not ideal, as the benefit of type-safety would then be lost again.)
I don't know if you're familiar with Typescript. Would you be open to a typescript migration of this adapter (if I do a PR)?
Hi Simon, first of all thank you for your pr's and hard work! Appreciate your collaboration and its more fun to make this stuff together :)
Yes I am familiar with Typescript and also build already an adapter in that language (WlanThermo).
Honestly I am a little to lacy to maintain all typescript relations, and from experience its harder to understand the good for starting developers which I made me a little afraid that would block collaboration.
But as you seen, there is not a lot of collaboration anyway ;), yes aim fully open to make an migration.
My time is little occupied but happy to receive an PR.
For state definition me could use mz example from wlanthermo https://github.com/DrozmotiX/ioBroker.wlanthermo-nano/blob/main/src/lib/stateDefinitions.ts
As I saw you recently added some @type jscomments. There are quite a few "objects" around and figuring out what properties exist on each of them takes (i my opinion) unnecessary amount of time and is prune to undefined errors.
@DutchmanNL . I don't know if you're familiar with Typescript. Would you be open to a typescript migration of this adapter (if I do a PR)? PS: Typescript is a superset of js, so just adding / using plain javascript is still an option then (although of course not ideal, as the benefit of type-safety would then be lost again.)
@jimmywarting any specific reason you just downvoted?
It's just that i prefer buildless setups and favor plain vanilla javascript over typescript syntax.
it's still possible to have type safety and IDE help with checkjs, allowjs, and strict combo. and using jsdoc.
I know typescript, i have been working with it for a long time... and i just hate the syntax... it's so unreadable at some times
developers which I made me a little afraid that would block collaboration.
Yeah can see that point. But the great thing I like about TS is that its optional to add type-annotations (despite some eslint complaints possibly 😄 ). So everyone could basically just "collaborate js (inside ts files)".
But as you seen, there is not a lot of collaboration anyway ;)
😄
Don't mean to be insulting or anything but didn't see you anywhere else involved here. Do you just go around github and downvote anything containing "typescript"?
To be clear, I didn't use a lot of jsdoc before because I prefer typescript for multiple reasons.
It's just that i prefer buildless setups and favor plain vanilla javascript over typescript syntax.
Sorry but I can't agree on this. For for example a simple string-type-comment maybe, but not for more complex stuff. Take for example this (from: https://goulet.dev/posts/how-to-write-ts-interfaces-in-jsdoc/)
You find this (for me kinda random comment) somewhere:
/**
* @typedef Address
* @prop {string} street The street
* @prop {string} city The City
* @prop {number} zip The zip code
** /better to read than this?:
export interface Address {
street: string;
city: string;
zip: number;
}It's still possible to have type safety and IDE help with checkjs, allowjs, and strict combo. and using jsdoc.
Setting up all of this is really better than just using typescript? (And the argument of the developer not having to care once its setup once for the repo - same true for typescript).
Also, Doesn't the IDE than have to constantly parse the comments (I assume the types can be more easily infered when already having typescript. I know maybe kind of weird argument because this is really NOT an issue / performance consideration but so is a development-time build step in my opinion, because at the end the runtime doesn't care because its compiled js anyway.
It's just that i prefer buildless setups
TypeScript is becoming more and more popular and natively integrated with stuff like ts-node. So buildless setups are also possible with ts.
PS:
It's just that i prefer buildless setups and favor plain vanilla javascript over typescript syntax.
Then I guess you won't be happy with the direction that even JS itself is seeming to take: https://github.com/tc39/proposal-type-annotations
But as you seen, there is not a lot of collaboration anyway ;), yes aim fully open to make an migration.
My time is little occupied but happy to receive an PR.
Thanks for clarifying.
No promises / ETA but maybe I look into doing "one" more PR 😄
i really don't want to go into an argument about ts vs js again. it's not healthy for me, and i'm tiered of it. i just have to accept that other ppl have other preferences about what they like. you ask for my downvote reason, and i gave it to you.
You find this (for me kinda random comment) somewhere:
yes. i do.
even more so with proper highlight coloring:
i find that project using jsdoc often more have documentation / comments as well written to it. unlike most typescript project that only use typing.
for it to be equal it would have to be written as:
which requires more lines...
but if you want something really compact than you can write it as this which is more or less like typescript syntax.
But i often write code in such a way that i don't need to write type interfaces or even jsdoc sometimes.
TypeScript is becoming more and more popular and natively integrated with stuff like ts-node. So buildless setups are also possible with ts.
then i guess you haven't been updated with the counter trend such as svelte and others ditching typescript? i agree with every single word that comes out from Rich Harris.
stuff like ts-node. So buildless setups are also possible with ts.
try that with browsers... and without using node, bun or deno and just a simple server such as php or python or whatever. see how you like it then... ts-node have been a nightmare to work with when it came to ESM, it might have gotten better now, but it was a long time since i checked that out.
Then I guess you won't be happy with the direction that even JS itself is seeming to take: https://github.com/tc39/proposal-type-annotations
that proposal is really bad. I have been following that as well and i hope that it dose not land, it dose not promise any real low level type system and dose not guarantee that types is of a certain type. it's nothing more than just annotation that would increase the complexity of the language to parse extra tokens and slow down js parser. A better proposal would be ecmascript-types or for the heck of it... wasm.
reasoning
Native/Runtime Typing vs Type Annotations aka Types as Comments
This proposal covers a native/runtime type system and associated language features. That is the types introduced are able to be used by the engine to implement new features and optimize code. Errors related to passing the wrong types throws TypeError exceptions meaning the types are validated at runtime.
A type annotation or types as comments proposal treats type syntax as comments with no impact on the behavior of the code. It's primarily used with bundlers and IDEs to run checks during development. See the Type Annotations proposal for more details.
you ask for my downvote reason, and i gave it to you.
thanks anyway for given your insights on this matter. Just read some of your other comments on the tc39 proposal for example. With some points I can agree, others not.
i really don't want to go into an argument about ts vs js again. it's not healthy for me, and i'm tiered of it.
Then I think it's best to just leave it like this...
Thanks for clarifying.
No promises / ETA but maybe I look into doing "one" more PR 😄
Cool Thank you appreciated! No rush better do it right than in a hurry 😅
Are you familiar how to (start) building an adapter in Ts for ioBroker? Otherwise more than happy to help
In basic it's best to use adapter creator to create it new baes in TS and migrate code functionality into it as TS requires some other dependencies and integrations
Are you familiar how to (start) building an adapter in Ts for ioBroker? Otherwise more than happy to help
No, not yet 😄. Was planning to get into iobroker adapter development / core concepts already quite some time. Basically thought it would be nice to not just create a new useless adapter, but actually do something useful and get this adapter some (quite needed) updates while learning. For example while implementing Select also took me some time reading iobroker docs to understand basic object concepts with common.* and finding out about common.states (was kinda looking way to long on / searching for "iobroker enum" - but enums are actually quite something different in iobroker than you would know from typical programming 😄 )
Thanks for the offer to help, while mention you when I face issues.
In basic it's best to use adapter creator to create it new baes in TS and migrate code functionality into it as TS requires some other dependencies and integrations
This was basically the plan as I'm also thinking about migrating to the new admin5 jsonconfig in the same process.
@SimonFischer04 sounds like a plan and good a approach if you ask me :)
let me know if you need something, I am also quite often in our discord community and for adapter development we have our discord & telegram channels, are you already a member or reading some of those ?
admin in JSON config would also be nice, didn't had the time yet to do as there is some complexity involved with Current way the table is build which was not possible that way a real ago in JSON config but also there new things have been implemented.
I am thinking of adding a button here to start the cleanup proces of devices, that must be done by using messaging.
could be a start of need to rebuild in JSON config anyway before adding old school code
let me know if you need something, I am also quite often in our discord community and for adapter development we have our discord & telegram channels, are you already a member or reading some of those ?
as you already found out, just joined 😄
admin in JSON config would also be nice, didn't had the time yet to do as there is some complexity involved with Current way the table is build which was not possible that way a real ago in JSON config but also there new things have been implemented.
will check out if its possible now / i can get it to work
I am thinking of adding a button here to start the cleanup proces of devices, that must be done by using messaging.
could be a start of need to rebuild in JSON config anyway before adding old school code
Same reason why I didn't add #152 to my first PR, as I also didn't want to implement it in the old index_m
@DutchmanNL so just read you telegram / discord messages. So you are working / looking into the jsonconfig migration?
@DutchmanNL so just read you telegram / discord messages. So you are working / looking into the jsonconfig migration?
yes, I will do some tries here with the examples we got. Still have an issue left for the secure code and how to store it but at least will play with the dynamic table to see if that's a solution for us.
Implementation of JSON-Confog ready for 95%, I will make a new release this afternoon and than that milestone is ready
Before we start TS I want to exclude some regular function already used quite often in my adapters, created a lib for that (yes in typescript) which I will implement
(PS, did build some nice gimmicks with it wasn't even aware that it's possible to have this kind of front-backend interaction like wrong password)
If that's done, we are basically on version RC1 (release candidate for stable) and I would like to put this version 0.5 or 0.6) to stable before Christmas
So if you would like to start the challenge for TS, more than happy to join also but let's handle it as separate Branch and no relation to current release plan
So if you would like to start the challenge for TS, more than happy to join also but let's handle it as separate Branch and no relation to current release plan
Great idea. Currently working on the dashboard release feature, but then happy to start with the TS stuff.
Great idea. Currently working on the dashboard release feature, but then happy to start with the TS stuff.
lovely! as I move more and more to a central approach (I have quite a lot of adapter in my org) I will transfer all of them to TS soon (and in fases during the year)
Appreciate your help here !
0.5.0 with rebuild admin interface released
Before we start TS I want to exclude some regular function already used quite often in my adapters, created a lib for that (yes in typescript) which I will implement
@DutchmanNL any progress on this so I can start with the ts stuff soon?
Before we start TS I want to exclude some regular function already used quite often in my adapters, created a lib for that (yes in typescript) which I will implement
@DutchmanNL any progress on this so I can start with the ts stuff soon?
I am so sorry not responding earlier, my health and private situation dod not allow it for which please accept my apologues :(
would you still be interested to run this journey together ? as I still think typescript can be interesting in this adapter as the usage of the lib allows easier integration and troubleshooting
I am so sorry not responding earlier, my health and private situation dod not allow it for which please accept my apologues :(
No problem. Hope it got resolved and you are doing well again.
would you still be interested to run this journey together ? as I still think typescript can be interesting in this adapter as the usage of the lib allows easier integration and troubleshooting
Yes. I have some esphome devices running here already and more to come.
Moving to typescript and getting adapter to stable would be great.