Video details

TypeScript Berlin Meetup #7 - Anil Kumar - TypeScript pitfalls to avoid for a great Dev Experience


◭ In this talk, Anil will demonstrate frustrations and excitement with Typescript during the apps development onboarding for headless CMS and commerce solutions. In addition, he will share three mistakes to avoid creating an excellent developer onboarding experience with Typescript.
◭ Anil Kumar (@anilbms75) is a Product Manager at Contentful. He is a community builder & prototyper with 10+ years of Frontend product development experience from companies including SAP & Sapient. He has been speaking, writing about rapid prototyping tools, running and facilitating the prototyping community in Berlin.
◭ This talk has been recorded during TypeScript Berlin Meetup. Join our TypeScript Berlin Meetup group here:
------------------------ 📚 Resources:
✅ Subscribe to Prisma: ✅ Get help from the Prisma Community: ✅
Learn more about Prisma: ◭ Website: ◭ Docs: ◭ Quickstart:
------------------------ 💬 Connect with Prisma: Twitter: Instagram: TikTok: Facebook: LinkedIn:
------------------------ Prisma sponsors human-reviewed, professional closed captions for ANY video valuable to our community (for example, about: Node.js, TypeScript & Type Safety,
Prisma, databases, etc). Get your FREE captions here:


So this is one of the I I kind of thought like two weeks ago and it's good that we have a lot of react topers here. And can you tell me what's the problem here? I know the item is the implicit any of type. And how can I fix this react problem? Any guesses. Should be is unknown. The problem problem is for me is I don't want to learn TypeScript here. I want to get my job done. I want to try out my application here, but I was stuck with this commenting thing, insisted any make it as I just want to ignore this error. I don't want to deal with error. I just want to ignore this. Okay, sound good. I'll come to that. I'll come to that. I I couldn't find out one answer like I did. Just like Googling. I tried to look into stack of flow. I went to GitHub issues. I have an answer, but I I'll get the answer a little bit later. Just my introduction. I'm a comma. I'm a technical product manager at Content. So and before that what I'm talking about. The context here. I want to give you a quick introduction about what's the headless solution. I've been working on the Headless solutions recently, like a couple of years. So at Content Full, it's a headless content management system, mainly building websites itself as a content through API's API first approach, and we have a user interface for the customers who want to build content like update content there. And mainly the content creators work with the interface. And this is where the devil Lopers comes in. Like developers build apps on top of content web app using app framework. That's where we build a custom workflows which fits to each customer needs. Similarly, before Contentful, I was at Commerce Tools same thing, but focused on the ecommerce sector. So Ecommerce API API first approach, same thing. So our developers again, the app developers are building apps to customize the customer workflow each company has needs. So in short, in one way we want to build some kind of marketplace where developers can build some apps and they can publish it and companies can use it to fit their workflow. Why? I'm talking about this. The reason I'm talking about this app developers are because running the UI component, building an app is just one part of their old journey. For example, they have to know their SDK, they have to know the product. For example, at content sold, they have to know the outs of products. Products like terminologist like content model content types entity. Similarly, there are other problems they have to tackle it. And for them, building the interface is just part of it, this part of their journey. And most of them they start with prototyping it. They're not producing a production code they want to test with their code and what I see the biggest challenges. A lot of example starts with TypeScript. And the first example I showed you that's even I struggled. I wanted to understand how our developer our journey looks like I and this is also one of the examples you see here. This is also one of my code, and I was trying to run one of the other examples and you could see that I end up having a lot of ignore commands. Of course I could have put it to the old file itself, but I was end up having like putting a lot of signals. How can we make this better? So. To coming back to the first question as so I'm just taking a little bit different example here. But still the problem is then I wanted to ignore it because my focus was more on trying to see the puzzle, how the application works, not to learn the TypeScript here. And of course I tried with a different option. And one which worked for me was this one and the only thing like compared to this one. And this one is like having it in second line. This is the one which works for me and the other one by trying out a different approach this one. Also, these two approaches work for me. And this was like I was the journey I could figure it out was by Googling looking into the stack overflow trying out my research. It was not straightforward and you could imagine that not our app developers are experts, react developers or TypeScript developers. They might have junior developers. There are some developers or coming from backend. They might not familiar with it, and they could really get stuck and just wanted to also talk about jobs to be done. How many of you are familiar with jobs to be done? Framework. Okay, so the JavaScript done talks about there's a famous too. People don't want a quarter inch drill. They want a quarter inch hole. When I apply this to my problem. I don't want to learn type script. I want to see how the application looks like how the application works. Right. So how can we make our applications? How can we make our documentation so that it gets our app developers jobs done right. As a developer, I want to get to see how this puzzle fit together and how the data flows. And I don't want to spend most of my time on digging deep into getting expertise in TypeScript. And there are other ways looking into your developer experience or developer onboarding is looking into how the developer experience looks like for your products, especially if you have an app products like a marketplace apps. So I could also add some of the two most like, I could also start looking into getting started looking into dogs. And if I don't find something, I Google it look into some problems stack overflow. I checked or and sometimes I check out GitHub issues. So there are some things you need to consider, like the different paths for experts and juniors and different happy paths and side path and negative parts as well. And this is a code from Sara from the just to work at. Notify. So one of the reasons people leave leave your product without giving you feedback is with your bad documentation tutorials with a bad onboarding so they won't come back to you. They won't give you a feedback. And other question is what's your favorite documentation site? Have you used any product, any favorite documentation site you like using it? Good. Nice. So. Yeah, I definitely. I agree with a couple of year stripe definitely. I also like the stripe one. I also like a Algolia and Filio in the same direction where they take you the journey of the beginner developer. They take you to the kind of experience the knowledge in an interactive way. That's great. So when I look at the journey map, when I apply the jobs to be done for the documentation, it can have like three kind of feelings. One, you really happy like your happy path. Like you really enjoy working with that. You get a success in a short amount of time. And there are situations where the situation like me like in the first example I showed you like I get stuck, right? And I'll can we fix these issues. How can we consider these documentation for different audiences, like beginners experts, intermediate and at the same time also think about the best practices, right? And like you said, I think the biggest thing I really like about TypeScript is about I don't have to visit documentation. Side this is an example from the Commerce Tools SDK, the Commerce SDK and I use the Commerce tool TypeScript sticking and I don't have to look into my documentation. I can just put a point and I can just press control space. I get all the options. What I'll do is I can call and also get what parameters I have to pass and what's possible. What's not possible? I don't have to switch to documentation. Side That's a great benefit. But how about how about if I want to use the other problem is what I see from our user application developers. They want to use a JavaScript library which has no support node types and the application itself is a Fax to DAP. And of course they can use any type Anian they can build it. But this is also one of the problem, right? How can we support them? How can we support even of course, most of the JavaScript libraries are Typesafe. Type declarations are available. But what if some of the JavaScript libraries don't have support for type? And if our app developers wanted to use that library? This is also one of the pain point with using TypeScript project and examples only having TypeScript examples. And I have a couple of tips like how we can fix this again, this is just my abuse. I'm also happy to hear your thoughts on it. There's a concept called friction locks at Stripe. Anybody who joins Stripe as an engineering team, they go on doing this onboarding session. They write all the problems they face in terms of onboarding. What are the problems they had with the documentation in terms of interacting and consuming the Stripe APA any kind of issues they find like they Google it. They go to stack overflow, they find out some video tutorials, they lock each and everything so that they can share it with their employees or responsible for their experience to make this documentation better. So one way is having such friction locks companies like building apps platform for developers that could really kind of already give you some kind of feedback where we could also make our documentation better. So it's also definitely helpful for our consumers as well. And other other thing which really works for me is about pay programming, a programming with our consumer and I do a user research and user testing. Sometimes they just don't share what they mean and what their solutions today. And when I do a pair programming, I see that what alternative parts they are doing today to get their job done. So they sometimes Google it or they sometimes have their own packages and they use it internally. And I think this pair programming can also help us to understand their paying and also give us more insights about how we can solve how we can provide a better documentation for calipers this also again, my thoughts or just idea how about using unknown instead of recommending any by default? For example, the case here like I've seen one of the quickest way to get into type script. Or you want to use some JavaScript libraries. You quickly add any and get your job done and you end up having a lot of any. But the question is do we get a benefit of TypeScript? The benefit of TypeScript is like giving a more static type check. And in this example, how many of you are familiar with are you using unknown types? Okay, then I have to explain more or yeah, this is a great way. Like or kind of more like giving more type checking for any instead of using any. So this example does don't know this kind of give you like I cannot assign this type unknown to any of the types other than any any or unknown. So for example, here in this example, I number six. I'm trying to assign the variable on counter to the counter, which is a variable of type number. I get this error that hey, type on on is not assignable to the type number. And same thing goes like I cannot randomly call some methods, and it also gives me that a get value does not exist on the type unknown. So in this kind of recommendation could also kind of give app developers or force Stem to think in types and also could give them more building their project more towards our type. Yeah. This is a recent JetBrains survey. How many of the JavaScript developers wanted to try JavaScript developers wanted to try TypeScript this year is 14%. And how can we make them more welcoming? How can we make them more documentation and give them in a better way so that they continue using it? Continue getting benefits. And same thing. There is also a recent survey from a stack of Flow developer survey 2021. And here you could see that nearly 72, 73%, which is nearly three fourth of developers really love using TypeScript, and like nearly 25% or a quarter of them don't like using it. And how can we make TypeScript a great developer experience so that we could reduce this number? Okay, that's all I have. I'm open up for questions. Thank you. The thing the video crews looking. Asking. Yeah, I just didn't get why unknown is better than any since you want to get the job done. And if you use a known the job is not done. You still have the type checking. Yeah. I mean to say that then why should we use type square price? You don't have to use TypeScript. If you talk back, I think we should add another option. How many developers from the transition from TypeScript JavaScript and to the survey? And in the beginning you said that as far as I get the most examples you see on TypeScript and you just want to run the example and you don't know what to do. So Firstly, you can take a signal to the beginning on the file. And the second thing you just use any should you type everything you see in the example with unknown and then create any other types? Yeah. Yeah. The reason I added this point was again, this is my view. It's not a recommendation I recommend. So I was like everywhere I saw only recommending any. Like if you want to get into your job done any. But I didn't see many of people are recommending using unknown. I feel unknown was better way than using any. This is just my view. But you had the slide with any and unknown counters and see then if you use any, the compiler is okay with that. But if you use unknown read, we compile or no. It'S going to throw a as you can see here on Lamb six and Line is already giving you that the project is not compiled. Job is not done. Again. I'm trying to say is that a lot of examples, at least this is you right. This gives you some hint. This gives you some hint rather than the purpose of type script is to type check. And like you said, I would just use a tier signal to the file and getting my job done. But this was like more about how can we the reason I added this point was like I saw only examples of any. If you use any, then there's no point of TypeScript. Right. That type track you miss the benefit of TypeScript. So if you want people suffer and loan type trip, you create examples with unknown so they can change if you need to flow. No, I'm not saying use unknown. I'm just saying that kind of my view. Like why there are no examples about unknown. I see only the examples with only any. In that case, it could tell you an instant object actually through the number that I got to do that. The point is that the context price. So the context is your working with code, which is the boundary condition and you don't know what you're investing, then it's safer to save it is unknown. So you're forced at run time to do the checks, and while you're going through the check, you have the certainty that the code is always going to be performing how you're expecting it at the compile time at runtime right. Any instead allows you to say whatever I'm going to take a chance and probably things will explode in production. Not my fault in the context of trying things. And I said you get why. So I guess it's a problem of type first design, right. You start from the type and then you get the rest of the project to sorry. Thanks. Hi, I'm Nick, and I apologize if this question is a bit muffled because this conversation just gave me a question. My question is based on your thought of getting stuff done and putting things out. Type trip requires a bit of an overhead in terms of time and effort to drag types and to think about it in that way feature first and what I'm going to do with it. But for companies that are young, relatively, they have big enterprise. Their goal is to put out features the same concept that you're pointing out, and they would most likely prefer saving that time and just implement using the technology versus using it. Right. And my question to you is how much would you advocate for that time to be used at that time? Like when the project is being set up, it becomes useful like that. There's autocomplete and whatnot versus not using it and then facing the consequences later, like the friction of going back all the way. Do you think it's wise for a company to do that? Because this is a technical debt that comes along with it that they will say, okay, we'll do it later, then later. We don't know when it comes. It's a natural habit for developers. A. I want to push this feature right now, create an MVP and then start doing this. How much would the advocate developers to stop thinking like that and work like that with types as compared to doing it later? Okay. If I understand your question, right, do you recommend doing it in the right way like with all the types or you do it like quick fix use any and get it done. Is it for the app developers? I just want to ask you more context on my perspective and context. Not for an individual developer, a team of developers that's working for a company which is for profit. So they have stakeholders and they have to put out stuff constantly. And there's like a small balance between do it later versus do it now. And because I type trip is pretty strong. Like I've used it for over four or five years now, and I know this has benefits, but would you think it's wise to ignore all of this and do it later? Yeah. I would ask the bigger context is the developers who are working on their TypeScript familiar? Are the experts are totally new to this type script. There are different strategies where you can migrate, bring JavaScript projects to TypeScript compatible. There are different strategies. Yeah, I would just see the project situation. The developers, if they're new to that's good, they need some time to adapt and learn. Would spend more time on investing there rather than forcing them to put it TypeScript type safe. I would spend time on it falls. That might come if they don't do it. And after a year of writing code without really considering types, and whatnot do you know of any pitfalls that might happen? No, I don't know. Maybe others can answer. I don't know. I. Would like to answer your question. You need to compare it by how many issues you might receive in production as you are using in four or five years in production. You are not seeing the issues that might come because of not using it, and that's why it might look like there might not be any benefit. But if you don't use it, maybe start this thing that you are not using that script and compare this thing. There is no compassion of using it. Start doing it and compare it and then make a decision. I think in a company talk about what efforts are they going to take and what kind of benefit you might get. And when you start talking about numbers, everything makes sense, actually. So probably once you start doing this thing of not using types and run into production issues more frequently, then it would start making sense that let's do types are my question was more that might I would say that. You might be able to see the. Pitfall would be when there are many people working on your project and they are changing very frequently. That's when you will see the pain of not knowing enough things and still pushing through the features. And in the end, like Nikita Hi. Good. Thank you.