export more interface in *.d.ts

WhitestormJS / whs.js

:rocket: 🌪 Super-fast 3D framework for Web Applications 🥇 & Games 🎮. Based on Three.js

MIT License

6.15k stars 391 forks source link

export more interface in *.d.ts #327

Closed looading closed 7 years ago

looading commented 7 years ago

Describe your issue here.

Why not export CameraComponentParams 、 RenderingModuleParams and so on in typescript module? Then i don`t need to redeclare those interface in my project.

Version:

[x] v2.x.x
[ ] v1.x.x

Issue type:

[ ] Bug
[ ] Proposal/Enhancement
[x] Question
[ ] Discussion

Tested on:

###### Desktop - [ ] Chrome - [ ] Chrome Canary - [ ] Chrome dev-channel - [ ] Firefox - [ ] Opera - [ ] Microsoft IE - [ ] Microsoft Edge ###### Android - [ ] Chrome - [ ] Firefox - [ ] Opera ###### IOS - [ ] Chrome - [ ] Firefox - [ ] Opera

hirako2000 commented 7 years ago

Hey @looading , I don't know I guess. Just tried now to create say a RenderingModule in the whitestorm typscript boilerplate app, it recognises types of the params without me having to redefine the interface of that params:

How would exporting specifically the param interface help the compiler and/or IDE? I might be missing something?

Note: I'm not against exporting nested interfaces if that's the recommended practice. I think the reason I did not is that it pollutes scopes. I might have been wrong.

looading commented 7 years ago

Yes, you are right in the case which your image showed. Here is my case:

rendering is a@Input property, here i use the type RenderingModuleParams . Is it a recommended practice? If it is recommended, there are no RenderingModuleParams exported, so i should redeclare.

hirako2000 commented 7 years ago

OK I get it (I think).

You are specifically importing a module that does not exist, because as you said, it is not exported. Btw your editor weirdly does not highlight that. See my VSCode editor lints it as an error:

What I did in my code, is that I simply pass the fields directly. I'm not trying to import, it's inlining values passed to the function, thus no need to import the interface.

Perhaps I should have either:

Made those interfaces anonymous to prevent confusion and people even trying to import such interface. or
Export those interfaces for people who like to import them and assign values to structured/typed object before passing them as parameter values.

I don't mind getting whs to export all param interfaces. unless it pollutes the scope too much.

Thoughts?

looading commented 7 years ago

I agree with you. There may be some wrong in my VSCode editor lints. My thoughts is that：

export those interface which may be used out of the whs library.It`s optional. Do not expose those interfaces that only be used in the whs library.
As for the scope of pollution, we need to make a choice between the two.I prefer the former.

Of course, I will follow your decision.

hirako2000 commented 7 years ago

sorry I didn't have much time lately. I reviewed your proposition, along with your code; I do agree. I've just made a change to export all params interfaces. imo it has to do with typed assignment, which I don't use myself, but your code shows it's actually a common practice.

If you mind code reviewing, it's just adding a single word to all interfaces :)

looading commented 7 years ago

@hirako2000 Thank you very much.