nextcloud-libraries / nextcloud-vue

🍱 Vue.js components for Nextcloud app development ✌ https://npmjs.org/@nextcloud/vue
https://nextcloud-vue-components.netlify.app/
Other
214 stars 84 forks source link

[FR]: TypeScript support #841

Open janis91 opened 4 years ago

janis91 commented 4 years ago

It would be very beneficial to add TypeScript support through a declaration file. I am currently working on porting my app to Vue.js based on TypeScript. I personally feel lot more comfortable with TS than plain JS and I think it might support other app devs as well, when they think about using this shared component lib.

skjnldsv commented 4 years ago

Hi @janis91. Thanks for raising this question! Typescript rise the level entry rather quite high. We talked about it before and decided to not use it for our apps. Nonetheless, we do use it for our libraries @nextcloud/xxxxxx. So this questions is an interesting one to ask ourselves for the components library.

We don't get much contributors here and some components are already quite complicated. How much work do you estimate to implement this here? Because we're all running on limited ressources and it's something to consider in the balance :)

cc @ChristophWurst @nextcloud/vuejs

janis91 commented 4 years ago

Hi @skjnldsv. I think there are a few things to consider: Even though you don't have to use TS in your app, you can benefit from typings because of IDE autocompletion and checks based on them. So especially for libraries there is a benefit.

I'm not very familiar with authoring a component library or libraries that provide typings in general, so I can't say, if this is a big deal (considered the limited time). I think there are some alternatives:

  1. Refactor / Rewrite the lib in TS to get types strongly connected to the code (lot of work initially; maybe some more work when developing in the future; potential contributors could be daunted, because they don't know TS, but on the other hand could also benefit from the typings, when contributing, because they'd get a lot more feedback directly, if everything fits code-wise)
  2. Provide the declaration files loosely within the repo. (not much work initially; should be considered whenever something is changed API-wise; contributors might ignore this, but maybe no TS knowledge is needed to contribute)
  3. Add typings to DefinitelyTyped. Much more loose from the repo. (like 2, but worse?)

I mean, as I am developing my app in TS anyway, I will have to provide some kind of declaration anyway within my project. Still, I won't type everything - just what I use / need. I think it should be considered, moreover because Vue itself moves in the direction of TypeScript with version 3. This of course doesn't mean you'd have to use it in the future, but the community will be much more aware of it in the future, I guess.

Just my two cents.

skjnldsv commented 4 years ago

I think it should be considered, moreover because Vue itself moves in the direction of TypeScript with version 3.

Some reading about this? :)

janis91 commented 4 years ago

Some reading about this? :)

https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf

skjnldsv commented 4 years ago

The codebase is also now written in TypeScript. Although this will make proficiency in TypeScript a pre-requisite for contributing to the new codebase, we believe the type information and IDE support will actually make it easier for a new contributor to make meaningful contributions.

Thanks for the read @janis91 :)

susnux commented 1 year ago

What do you think, would this something for the next branch? If yes I can contribute the required changes (should be not too much work if we do the migration step by step).

cc @skjnldsv @raimund-schluessler @ShGKme

skjnldsv commented 1 year ago

@susnux depends on what we're talking about. If this is only about typescript support and allowing it in components it's fine. I'd like to make sure thi sis not about using the same component syntax you used in dialogs as I think this is far too complex and raising the level entry too high :)

susnux commented 1 year ago

depends on what we're talking about. If this is only about typescript support and allowing it in components it's fine.

Yes exactly to keep it simply I just would allow using Typescript so that type definitions for our components are generated. Allowing users to write apps with first class Typescript support :)

I'd like to make sure this sis not about using the same component syntax you used in dialogs as I think this is far too complex and raising the level entry too high :)

As said this was not planed, but fyi I decided to use the script-setup style components in dialogs to make it easier for beginners to contribute, as it removed much boilerplate code and it is the recommended style for writing vue components. Meaning everybody who starts learning Vue with Vue 3 is probably using composition API and if started with Vue 3.3 probably script setup.

But I did not plan to rewrite everything using script setup here ;-)

ShGKme commented 1 year ago

I see both advantages and disadvantages of using TS in Vue frontend.

While it may help with developing some complex components and prevent issues, it increases complexity as well.

Another problem is mixing JS and TS in Vue. In some tools like ESLint, we cannot divide Vue JS and Vue TS components. For ESLint, both are just .vue files.

Allowing users to write apps with first-class Typescript support :)

Without full migration to <script setup> it doesn't change much for lib users. @nextcloud/vue has mostly only Vue components. props and emits may work without TS, typing slots works only in SFC Setup.

However, it is not required to write a library in TS to have first-class Typescript support for end-users. We only need to have typings somehow.

to make it easier for beginners to contribute, as it removed much boilerplate code

IMO, it is discussible. I don't think that Composition API is easier than Options API for beginners in general. I still see many developers who learn Vue with Options API first. And it will be a problem for the first time for full-stack developers and other contributors who don't "live" in Vue.

Especially when Composition API is used in new <script setup> with compile-time stuff.

<SFC Setup> reduces "boilerplate" but also loses a "structure" of Options API.

Though I really do not like SFC Setup with much of the compile time magic and macros, I must admit that it is a new "standard" in a Vue world, and new features are mostly SFC Setup related... Likely we will move to SFC Setup someday (some year :D) anyway.


So I'm fine with any solution here.

susnux commented 1 year ago

I created an example so you can see what is needed for Typescript support: https://github.com/nextcloud-libraries/nextcloud-vue/pull/4525


edit @ShGKme posted the comment the same time

However, it is not required to write a library in TS to have first-class Typescript support for end-users. We only need to have typings somehow.

That is true but then you have to maintain those type definitions, when using Typescript for the source you only have to maintain one place.

ShGKme commented 1 year ago

That is true but then you have to maintain those type definitions, when using Typescript for the source you only have to maintain one place.

I'm not sure that we cannot generate typings from JS and JSDocs. It definitely works in Pure JS, and may work in Vue, but I haven't tried it in Vue. So didn't propose to write .d.ts files by hand =D

skjnldsv commented 12 months ago

to make it easier for beginners to contribute, as it removed much boilerplate code

IMO, it is discussible. I don't think that Composition API is easier than Options API for beginners in general. I still see many developers who learn Vue with Options API first. And it will be a problem for the first time for full-stack developers and other contributors who don't "live" in Vue.

Seconded. This is why we had meetings and decided to go for sfc in the past. Because it's much easier for beginners.

susnux commented 10 months ago

decided to go for sfc in the past.

But SFC is unrelated to that, if you use Options API or Composition API inside you SFC depends on your taste.

But this is a bit OT I would say it would be good to have Typescript support, if you use Options API or Composition is a different topic (but as said someday we will have to discuss this, as all new features are done for script setup in Vue and composables can only be registered in setup functions which might get a problem with dependencies at some point).

Meaning for me having some kind of Typescript support (e.g. Options API but allow writing you components in TS) is fine for this issue here :)

dartcafe commented 1 month ago

Hey. I am migrating from vue2 to vue3 with ts. By importing and using the NcButton, I get an TS error in the IDE when defining the button type:

Type '"primary"' is not assignable to type 'ButtonType'.ts(2322)

How can I import the types to use ButtonType.Primary?

<NcButton :disabled="titleEmpty"
    type="primary"
    @click="confirm">
    <template #default>
        {{ t('polls', 'Apply') }}
    </template>
</NcButton>