Making friends out of TypeScript and Vue Developers

Ionic Framework Ionic Vue
1

Originally published at: Making friends out of TypeScript and Vue Developers - Ionic Blog

Here at Ionic, we’re big fans of TypeScript. Back when we were working on Ionic Framework 2.0, we made the move to go all in on TypeScript and haven’t looked back. When we shipped Ionic React, we made sure it used TypeScript out of the box and wrote about how to use TypeScript in a…

4 Likes
2

I was pretty unhappy when Ionic 2 went with TypeScript, which I hadn’t learned yet. That made me put off upgrading from Ionic 1, which I eventually came to regret. Fast forward a few years later, and now I love TypeScript and Ionic 5. But I get why people would hesitate. It’s a lot to change all at once.

1 Like
3

I mean, it’s not always a lot. I specifically call out parts in my post where typescript will do most of the type checking for you automatically.

4

Thanks for an awesome intro to the main benefits of Typescript.

As a Dev new to Vue and Ionic at once Typescript felt like just another thing to learn at first. I’ve come to enjoy TS mostly. But here and there I run into Typescript errors that take 30-90min to solve at best. The last ones took days, I’m still searching. It’s particularly frustrating in such cases if you pop open JsFiddle and your code works 100% out of the box. Then stick it back in the project and run into heaps of errors you don’t understand. It’s probably where most of us go… wait a minute…

I’ve grown to understand some of the most common TS errors and often look up the more obscure ones. But even then when you’re just starting out it’s not always immediately clear what TS is on about.

This is especially pronounced in an Ionic Vue3 project where for some reason the TS errors refer to totally different line numbers than what is in the code. It seems from my digging that it’s an open bug at the moment. But this makes debugging very hit and miss and often directly leads to days in debugging. I know the past 3days in my latest Ionic project where just spent hunting TS errors. I often just revert with git and start from the past checkpoint. If that means redoing 1-3days of work it’s often worth it compared to guessing what line number TS is throwing errors on. As a Dev new to Vue and Ionic I don’t exactly type this out in VIm like you do ;-). I also probably make some of the most obvious mistakes.

Lately I code and check line by line so I catch TS errors early on while I’m still coding a new line.

I think in time though TS is going to prove to be an invaluable asset. So I’m gritting my teeth and bearing the growing pains. Less debugging on very obscure issues later on is certainly worth it.

1 Like
5

Just loving all these confessions!

I converted after one project without TS (suffering many runtime pains) and disciplined myself to use Typescript. My confession is that I do cheat once in a while by using the any or unknown keyword, misleading Typescript and myself. That is why I add the comment “Hacky” to every line where I cheat.

I might be mistaken, but in my (Angular) case, my editor (vs code) tells me where I go wrong in Typescript at the moment I type the mistake.

I hardly look at the CLI output anymore these days. Nor am caught in Typescript messages in the browser that way. So hardly any need to look for line numbers due to TS issues. Runtime issues (if any) are mostly due to APIs and wrong logic

The editor and the app end result are my focal points. Creating and checking line by line, as u also mention.

Shouldn’t this also be possible for Vue, looking at the blog?

Otherwise, one would think there is an issue with the TS transpiler?

6

@mhartington Speaking as a new VueJs Developer in a first solo project TS causes extreme frustration when you spend 90% of productive time chasing implicit errors senselessly on working JS code. It’s Einstein’s definition of insanity.

I’ve spent time pushing through TS primers and TS is not hard but it does require understanding for the underlying code you’re working with. I can code VanillaJS off the top of my head. The hard part is when you’re learning VueJS and Ionic and Capacitor and along comes TS errors for days on end with senseless nonsense. To a new IonicVue dev this negates all the gains of using a framework.

So when you’re new to VueJs you’re forced to run before you crawl by this requirement. And I think this is where the Pushback from most of the VueJS crowd comes from. TS is inherently part of VueJs’ inner workings. So where appropriate it’s taught without much ceremony in Vuejs docs but you’re still free to mostly write VanillaJs almost everywhere else. I get why this might not be great in the long term.

When coming to Ionic though there’s still virtually no documentation for Capacitor and Cordova plugins that work in a VueJs+TS context. All the JS examples in Cordova plugins and Ionic example pages break over and over when you pull them into IonicVue. In the beginning it’s not immediately clear why and there’s so many stacks and dependancies involved that it’s hard to say where things break down. TS errors have nonsensical definitions that are written to apply to such a broad audience that they really don’t help much.

And then comes JS plugins like Quaggajs that replace depreciated Cordova Scanning plugins with no real Capacitor replacements yet. This leads to a new level of fun - no types definition. So not only do I have to type out my code but if I want to use the code of others I need to write type definitions for their code as well. This requires me to dig around in their code and try to figure out what they intended. The TS requirement effectively makes many JS modules completely useless in Ionic unless you want to spend even more fun time with TS.

Since over 90% of my time is already invested in solving TS issues I’m more keen to actually do something in my code that contributes to the actual aim of my project.

Effectively TS ads so much technical debt to a very tiny project that I may as well abandon the whole thing and move to a different framework.

For me the issue is not so much TS as the frustration of TS issues stopping all progress in it’s tracks. I think including example snippets in the Docs alongside React and Angular snippets will go a long way to alleviating much of the frustration for new users. But it is the tip of the Iceberg. TS is an advanced topic and not really worth it for tiny projects or beginners because it ads a constant hurdle to getting work done.

After spending some time getting to know TS I’m convinced I want to use it in the medium to long term but I can’t yet justify the time drain it creates in my project work.

The further I go the more I see why TS is so unpopular with VueJs devs using Ionic.

3 Likes
7

ok, there’s a lot here, so I’ll try to reply bit by bit…

The hard part is when you’re learning VueJS and Ionic and Capacitor and along comes TS errors for days on end with senseless nonsense.

When this happens, this generally means you will have a run time error. Saying that Typescript introduces these errors ignores that you’d have them at runtime.

So when you’re new to VueJs you’re forced to run before you crawl by this requirement.

I don’t fully agree with this since, as I stated in the blog post, typescript will do most of the type inference for you. You are only really forced to do something if you are being too dynamic or trying to change a data structure.

When coming to Ionic though there’s still virtually no documentation for Capacitor and Cordova plugins that work in a VueJs+TS context.

All of Capacitor’s docs provide typescript examples. For cordova we have a whole docs page on that here

https://capacitorjs.com/docs/cordova/using-cordova-plugins

By using the Ionic Native wrappers around the cordova plugins, you get type info you need automatically.

Quaggajs

Haven’t tried this myself, but a quick search shows that there is a version that is

  • Maintained
  • Provides type definitions.

But if there’s other libraries that you need, there’s the DefinitelyType project that can help. You simple install the types you need

npm install @types/<your-library>

All of which is covered on the typescript site.

Generally, I think what you’re describing is anyones reaction to learning something new. It’s less of “this is bad and causes too many headaches” and more of “this is new and I’m still learning”. Many other communities (angular and react) have seen the benefit that typescript provides to large and small projects, just takes some time to learn the process.

8

I so agree with you. I have been struggling with this on end. Often I don’t understand the errors and there are so many missing guides on TS + Vue + Ionic. Especially using Vuex in TS is full fledged HORROR for a TS beginner.

You mostly find JS for Vue guides/examples and the limited TS guides from Ionic clash with it at the moment. I found how to install missing types through @types.

Right now I wish there was a Ionic Vue in TS course online.

9

@Weltraumdrache what would you like to see in that course? When I was posting vue ts content it wasn’t getting a lot of engagement because folks didn’t like that I was using TS so I stopped and most of my stuff doesn’t focus on typescript.
As for vuex, I am staying away from it now in regards to typescript and using

composition API to manage state in applications, it is easier to manage and I don’t believe that vuex is final version yet

10

Vuex would be the big one for me. It’s very specific code and hard to understand.

In general I need to learn TS, where to put types and how. Ways to avoid implicit any errors. How and where to write custom types in Vue.

How to read the error messages and find the problematic code.

I’ve had a couple ones where I was so lost about typing objects and how to convert almost identical types. I don’t even know how I should handle objects and arrays which can have unknown and optional type fields.

11

Honesty I would focus on making sure I have a grasp of vue and ionic before getting caught up on typescript, typescript as the default for vue is relatively new and not specific to ionic

Opinion - As for typescript and vuex, honestly I wouldn’t even waste my time, the implementation currently is overly complex

12

For vuex…I wrote about that here…

13

Is there an easy way of using untyped Vuex (store/index.js) within Typescript components?

I’ve watched Maximilian’s Ionic Vue tutorial and this pure js way surely is easy enough but it threw type errors in my otherwise ok TS project.

14

So I just want to point out…you are spending a lot of time trying to avoid typescript or learn ways to not use. Vs the small amount of time it can take to learn typescript and apply it.

As I state in the blog post, typescript does most of the heavy lifting for you. It’s really good about guessing the kind of types you need to use and only requires you to declare types if you are

  • being too loose why your variables
  • using something very custom

Both of these though are address by using the any type if you don’t want to write your own.

As for Vuex…I linked to a post that shows you how to setup vuex with proper type support and gives you a sample project. It does all the work for you, and I walk through what the types are doing in the blog post.

15

Thanks Mike, I’ll check your post and will eventually try to apply what I have learned. For my last project I just really lacked any time to properly learn the used tech stack.

Regarding any I had problems figuring out how to use the any type down the line in TS (like trying to use array functions like .push() on it because it usually threw an error that it’s not available on type any or something like that.

I’m aware that this due to not fully understanding typing/infering/converting in TS.

When I would program C# in the past I wouldn’t have problems with types. It’s the way of bringing loose JS coding style together with TS. It’s a clash of expectations and coding habits.

16

My advice is to avoid any as much as humanly possible.

“Unknown” is problematic by definition, but generics do a great job of handling “not completely known”:

“Optional” is easy. You can “or” together union types like string | number, and Foo | undefined is equivalent to “optional Foo”. This is such a common construct that there’s syntactic sugar for it: foo?: Foo.

There are also utility types that allow you to turn properties from required to optional (or vice versa) using a more generic syntax.

1 Like
17

Just adding my two cents here as well (which I have shared elsewhere) since I struggled with TypeScript when I started my first Ionic and Vue 3 app a little over two months ago.

SPOILER ALERT: I love TypeScript now but it was a journey.

My background is over 10 years in C# and PHP (yes, PHP 7 & 8 now have optional types :slight_smile:) I much prefer types when I am programming. The two biggest benefits are error checking and IntelliSense (I am using VS Code). I also do front-end work and wrote some Vue 2, but this is my first project really diving deep into JS.

So, my journey started 2 months ago getting caught up on Vue 3, learning Vuex and Vue Router, being a noob with Ionic (by the way loving it so far!!!), and trying to understand TypeScript. As you can imagine, this was very overwhelming. With Vue 3 still being fairly new and TypeScript now officially being supported, there weren’t very many resources online to help. This article and the one on Vuex by @mhartington didn’t exist yet.

I started with TypeScript as that is the default Ionic Vue template project and was looking forward to types…until I tried adding Vuex. I spent hours trying to figure out types in Vuex and eventually gave up and got it working without (TypeScript only being used within Vue Components and not Vuex).

Then still being overwhelmed, I got rid out TypeScript all together. It was too much!

As I continued to work, I was second guessing my decision and couldn’t stand not having IntelliSense for my Vuex store. But, I kept telling myself, TypeScript with Vuex doesn’t make sense and is too much work to understand. It is going to be easier without it.

Then came another encouraging tweet by @mhartington about TypeScript a few weeks later. Not feeling good about the path I was heading down without types, I decided to give it one more try. This time I went all out with types everywhere, including Vuex (I finally found some examples online on how to do it).

In summary, I highly recommend sticking with TypeScript especially if you are coming from another typed language. It is definitely more up-front work, but I believe it is well worth it. I am also loving the other functionality like classes, enums and generics. I’ll be honest though that I still don’t fully understand the syntax that has to be used in Vuex to get types working. I am though definitely enjoying a fully typed store. As @aaronksaunders mentioned, the TypeScript implementation in Vuex is still overly complex. Hopefully this improves in future version of Vuex.

Final thoughts, just use TypeScript…lol. It WILL become easier over time.

I think we are still missing some good examples of splitting mutations, actions, and getters into separate files along with using Modules.

Thank you again @mhartington for your encouragement and advocacy for TypeScript!

18

Just threw this together hopefully to help explain things further.

1 Like
19

Thanks Mike! I think that will be very helpful for those starting out.

20

I have multiple videos and some blog posts on using vuex with ionic. I am just saying that just like redux and react, vuex isn’t always the best approach and there are multiple opinions to support that. Also, there are various ways to integrate vuex as you come up to speed on typescript but it is a process.

also @mhartington I don’t think it is always the case that people are “avoiding” learning something, sometimes you just need to be productive and deliver a solution to get paid… and if that means passing on learning/integrating typescript then that is what you need to do to get the job done.

finally, people learn differently, what is a small amount of time for some is longer for others; I have taught classes before and I see it all the time with student and adult learners