Flow or TypeScript typings about hybrids

[nsaunders]

Discussion copied from #31:
Sorry for the delayed response @smalluban.

After a bit of consideration, here are my thoughts:

• Authoring hybrids modules in Flow or TypeScript is ideal because it would
  • embed type safety into the library.
  • eliminate what would otherwise be a bit of guesswork by type definition authors other than you, given your complete mental model of how this library works.
  • possibly result in better / more specific typings.
  • possibly prompt minor design changes that allow for more expressive types.
• Regarding the point of not having to transpile the code one day:
  • I certainly acknowledge that this is likely to perform better and reduce bandwidth.
  • However, I think it is going to be a while before this is no longer necessary. Many of my clients are still using IE11--yuck!
  • The typical Flow setup simply involves a Babel plugin that only strips away the type annotations before other plugins take care of transpiling the code to ES5, etc. TypeScript appears to have a --target option that allows specific ES* versions to be targeted as well (see docs).
• If you have other reasons that the type definitions need to be separated from implementation, then the challenge of keeping them synchronized exists regardless of where they live. However, the flow-typed library has project structure and naming conventions for properly defining library version compatibility; and I assume the TypeScript analog has some way of addressing this problem as well.

TL;DR: My opinion (which is just an opinion, of course) is that writing the library in Flow or TypeScript is the best option; but, if the type definitions are to be separated, then we might as well follow the conventions that have been developed by the broader JS community.

On a side note, flow-to-typescript and flowgen look like interesting options for providing both options without having to define all the types twice. :-)

Anyway, thanks for the consideration, and I'm definitely interested in hearing more of your thoughts.

[smalluban]

@coedder I read your comment a few times, but I can't understand your point. This issue is about adding typings, that would help using the library with TypeScript ecosystem. Rewriting the library with TS is not required.

I would like to start with comments above exported functions in JSDoc or another tool standard. However, now I am focused on other stuff related to the library, so it has to wait.

[smalluban]

Good point. I planned to add typings from the beginning. Only it wasn't on top of my todo list. For now, I am finishing some new features, and then I take care of that. I should be done in the next month.

However, if you want to help with that, it also would be cool :)

[smalluban]

I think there is a way to still have untouched source code and typings inside of the repository. I looked at the redux:

1. Source code is JavaScript
2. Exports have comments with parameters documentation
3. Package.json has typings field pointing to index.d.ts
4. All index typings are defined in index.d.ts file

I would recommend the same way here. I will add point 2 to my todo list. I am not familiar with defining typings, so creating index.d.ts is an open case.

[g5becks]

Just chiming in here, I am willing to help write the typescript typings if / when you get around to commenting the exports with parameter documentation. I see you have a few in the docs already, so I’ll try my best to help out with that. This looks like a really cool library, I am a big proponent of types though so I can’t use it until it has typescript support.

I think classes try to do something than JavaScript don't need to do, and if we use hybrids is because we can use web components in "the JavaScript way": plain objects and pure functions.

I think strict types are the same as classes for JavaScript: try to do something than JavaScript don't need to do.

JavaScript (almost always) run in a browser (a JavaScript engine), and if you write 1 + 1 you don't ask yourself. Could the browser run this code? Not the case when you write for a machine (hardware), here you need know what can and can not do that machine, and in this case is where strict types fit perfect. For example: Here is the list of the different numeric types in Rust: i8, i16, i32, i64, u8, u16, u32, u64, isize, usize, f32, f64. Which one I need to use? Depend most of the time of the machine where the code will run; Machines have strict limits, so my code should be strict (typed) too.

Diodes? Transistors? Integrated circuits? Optoelectronic devices? Power sources? Resistors? Capacitors? Inductive devices? This are thing I don't care when I write code in JavaScript.

Classes in JavaScript? Why? Are not needed, the same for explicit types.

[xdvarpunen]

@smalluban TypeScript with JSDoc enables smoothly intellisense in VS Code 💯

[darrickyee]

Hi, I was wondering if there's been any progress on this? I am just starting to explore hybrids and it looks very cool, but a d.ts file with just typings would be super helpful, even without comments.

[Edit] Attempting to use hybrids in Typescript with VSCode, fyi.

[smalluban]

I will try to make some basic typings this week, I will update you when it will be done ;)

[smalluban]

@nsaunders @g5becks @coedder @xdvarpunen Ok, it took me a little more time, but here it is #80. It would be great if someone from you would like to do a review ;) I am not a heavy user of TS, so maybe some of the things could be written more in TS way (usage of type vs interface, naming conventions, etc.).

[smalluban]

I decided to merge #80. It was released with v4.1.0, and with minor fixes, in v4.1.1 I think basic TypeScript support is done.

For now, I am closing this issue. However, anyone who wants better support is welcome to comment here with suggestions about how to make it better. If applicable I will re-open the issue.

[gotjoshua]

not sure if the issue needs to be reopened but when following the general typescript recommendations for hybrids, I get errors on the Component definition when the interface is already defined above.

i can disable the error with this

// eslint-disable-line @typescript-eslint/no-redeclare

but i wonder if there is another way to not litter all my component files with those ts exceptions

[smalluban]

It looks that it is specifically the eslint rule, not the TS itself. Usually, when I use TS, I skip the eslint (as it adds marginal benefits). You can see here on the TS playground that it does not complain about declaration variable with the same name as an interface.
It is not only a shortcut, but if you export that variable, the TS maps to it its interface, and where the interface should be used (for example in another interface) you can just use that interchangeably.