Josh Goldberg - Learning TypeScript Book, typescript-eslint

{/ TAB: SHOW NOTES /}

This week we're joined by another great contributor to the TypeScript community. Josh Goldberg is the author of O'Reilly's Learning TypeScript and a core contributor to the typescript-eslint.

Twitter Website Book TypeScript ESLint

• https://www.learningtypescript.com
• https://github.com/JoshuaKGoldberg/TypeStat
• https://www.learningtypescript.com/articles/extreme-explorations-of-typescripts-type-system
• https://ts-error-translator.vercel.app/
• https://www.youtube.com/watch?v=7lyb22x9tcM
• https://www.youtube.com/watch?v=7nj3vgZjL0Y

Tooltips

Andrew

• https://www.npmjs.com/package/jscodeshift
• https://react-cmdk.com

Justin

• https://interval.com/
• https://github.com/coddingtonbear/obsidian-local-rest-api

Josh

• https://github.com/mattpocock/ts-error-translator (https://ts-error-translator.vercel.app) by @mattpocock. Great explainer for TypeScript errors.
• Laziness Does Not Exist by Devon Price, Ph.D. Helping me feel better about my work ethics & avoid burnout.

{/ LINKS /}

{/ Paste show notes /}

{/ TAB: SECTIONS /}

[00:02:26] Getting Into TypeScript [00:13:18] Josh's TypeScript Features [00:18:30] TypeScript ESLint [00:25:57] Writing a Book [00:34:06] The Good Parts [00:40:44] What's Next? [00:50:57] Tooltips

{/ TAB: TRANSCRIPT /}

Episode 35

Josh: I think good thing about it is that it really focuses on building up your understanding of how to use and what is the type, script type system before delving into the deeper features of how it interacts with things like functions, classes and so on. Like what is a type system?

Andrew: Hello, welcome to the dev tools, FM podcast. This is a podcast about developer tools and the people who make them I'm Andrew. And this is my co-host Justin.

Justin: everyone. Uh, our guest today is Josh Goldberg. Uh, Josh is an author speaker open source maintainer, uh, all this stuff in the type script ecosystem. Uh, and you've recently published a new book called learning text script. Congrats on that. Uh, really exciting to see. Um, so Josh, is there anything else you'd like to tell our audience about yourself?

Josh: I, I'm a pretty cool individual also once you get to know me. Uh, but yeah. Thanks.

Justin: You heard hear folks

Josh: Thanks to the introduction. Yeah. Uh, it's it's my first book. I'm very excited about it. Please give it five stars. I'm told I'm supposed to ask everyone to do that also buy it.

Justin: yeah. What is, uh, this is a little bit of an aside, but what is like. What is the process for writing a book? How did, how did you even, what inspired you to say? Oh yeah. I think writing a book is a good idea.

Josh: I've always liked type script since, uh, a long time ago. And I've also always liked the, the good software textbooks. I get a lot of value out of them. I know a lot of people like video or other modern formats, but for me, sitting down with a book where I can flip around, like physically see the pages in front of me, that's always been how I think I work best.

Um, O'Reilly actually reached out to me, uh, a little more than a year ago. Last spring I had been doing conference talks and blog posts and contributing to TypeScript itself and all those things kind of lean well towards having me write a book. Um, I'd also been working at codecademy at the time, which is a fantastic place to learn how to teach people because that's the company charter and we'd worked a bit on the learn TypeScript course that they released and might be expanding later this year, hopefully.

So it all kind of worked together. It was a nice little progression fast forward a year. And the, the thing was released. Spent about a year working on it. And, uh, I'm honestly really thrilled with the result. Uh, it's fascinating seeing how you teach a language evolve, like all the little nuances and what has to come before, what you don't really realize when you're just learning it for yourself.

[00:02:26] Getting Into TypeScript

Andrew: speaking of learning for yourself, uh, what originally got you into type script, uh, because of your talks at Ts conf, I kind of see you as like a type script figure, like, uh, in, in the community. So how did you get your start?

Josh: I got my start by writing a lot of really, really, really, really bad javascript. I made this project called full screen, Mario, which went viral. It was a remake of the original, super Mario brothers in JavaScript. Uh, Nintendo actually sent it a DMCA takedown notice, which at the time was the highlight of my life and career almost sued.

Um, but the code was terrible. Like it it's open source. I, I didn't intend for it to be an open source thing. It's just, GitHub has free hosting and now other people can see it too, I guess. But. Atrocious hundreds and upon hundreds of global variables and useless functions and unused code and someone on Reddit very kindly suggested that I use linting ES lint at the time already to fix it.

And I did. And then I tried converting it to type script. And in that process, I very much, the hard way learned how useful it is to have static analysis tools, take a look at your code and fix it for you, tell you where the things are, where the likely bugs are. Uh, it's not a replacement for testing or good architecture, but it's certainly a piece of the puzzle for writing actually validly good code.

Andrew: it helps you not live in blissful ignorance before type script. You're like, oh, there's no bugs in my code, but now with type script, you kind of know a little bit better.

Josh: Yeah, I've read recently a very good book. Um, oh shoot. What is it called? Laziness does not exist. And. That book introduced to me the, the, a more full quote, uh, where ignorance has BLIS his folly to be wise. I think a lot of people hate typescript because it shows them where their bugs are. But if you're willing to go through the emotional pain of slightly changing, how you think and fixing your bugs and architectural shenanigans, it's, it's very, very much worthwhile.

Justin: Yeah, it it's interesting in that it, like, it sort of forces you to express your intent a little bit more to qualify what you mean in, in places. And I, I almost look as it at it as a communication tool, as much as anything else, with all types, you know, generally it's like, we love like scripting languages that don't have types because it's like, you can like throw some stuff together really, really fast, but then it's you come back to it next week and you are like, what, what is this, what is this doing?

I don't know. It's like having types does slow you down, like in an intentional way and force you to express your intent. And, uh, yeah, I always thought that was kind of the beauty of typed language.

This is a common

Josh: Absolutely. It's funny. When you write a book, you tend to discover through research that common things, people, praise or hate on a language for. And I ended up calling this freedom through restriction that when you exactly, when you start JavaScript or Ruby or similar without types, it's beautiful. It's fun.

You can do it quickly, but by restricting yourself to use a type system, you end up getting more freedom and flexibility and how you can change the code long term. And eventually you realize that you you're never gonna be able to write UN typed code more than a few dozen files at a time. Again, it's just impossible.

Justin: we're attracted to design systems because design systems enforce visual constraints. And through those visual constraints, you can build more consistent, more useful, more discoverable UI. You know, it's like constraints are incredibly powerful for enabling you to do more than you could do otherwise.

Josh: Definitely I'm resisting the urge to launch it to a tirade about how good design systems are having been on a web platform team that, uh, implemented one strong agreement there.

Andrew: You'll you'll find strong

Justin: in the right place.

Andrew: yeah.

So let's move on to talk about a little bit about those Ts conf talks. Uh, my first interactions with you were sitting in an audience watching you abuse the type system to do fun and interesting things. So would you like to explain a few of those fun and interesting things to our audience?

Josh: Sure. First of all, thank you for, for remembering my talk. I really appreciate it. Um, I, I did not. Grow up as a developer thinking I'd end up doing conference talks and it's still bizarre to me that people are willing, let alone interested in listening to it. Uh, but yeah, this has sort of become a specialty of mine, which may or may not be good that I show people weird, stupid things you can do in the type system, purely in the type system, just with typescript types, not with runtime code.

And it's fun. It's catchy, it's gimmicky, but we use it as a vehicle to explore the features of the type system. The, the two goals are to make people get interested and excited about it. And then also to go over the features and my worry with them is always that people will look at it and think, oh my God, I have to do that to be a typescript developer, which is absolutely not the case.

The more of these stupid things you use, the worse please don't. Um, but the, the, the fun things I've done in the type system are, uh, oh, what, what was the first one? There was binary arithmetic, like manipulating 8 bit integers. That was the in person one. I made a tic-tac toe. Game, uh, I implemented a solver, but didn't put it in the, the talk.

I think it was a little too much. Um, recently I showed off, uh, in, uh, Prisma day in Berlin. How Prisma clients use these beautifully complex, uh, advanced types to make Prisma clients. Autogenerate like really precise code, uh, for those who don't use Prisma, it's a database ORM. It lets you generate a client based off of your database schema, like a type script client.

You can have things like include extra fields in your queries and it'll the types for those methods will add extra stuff to the returned object types for you. It's really, really fantastic. Um, I'm actually at time of recording about to release. And I think at time of release have released a blog post that is just a compendium of all the ridiculous things people have done.

As silly as my stuff has sounded. It's nothing compared to some of the ridiculous things people have made. There's a full on language that's been implemented in the type system people have made parsers tokenizes interpreters like runtime interpreters with a lisp syntax. It's absurd

would recommend not doing that.

Andrew: I put it in the same category as those like CSS paintings you see? It's like, sure you could recreate the Mona Aliso with, uh, gradients, but you don't really want to, but you learn a lot in the process of doing that. Uh,

Josh: absolutely. That's a good analogy. Thank you. I'm gonna steal that. I'll try to remember to give credit, but please yell at me.

Andrew: oh, it's okay. Steal my ideas. Um, uh, so I actually saw a tweet from you today saying that soon you'll be able to implement type script in the type system. Like what, what does that mean? Exactly.

Josh: Oh, oh boy. It's all coming together. I tweeted that walking back to the apartment for this conference or for this podcast. Yeah. So I mentioned you can implement a tokenize, which is like how a language turns a string into something it understands. So if you can implement a tokenize in this type system, why can't you implement like a scope analyzer and a type checker?

And I prototyped it out locally. I got a very basic one working with variables, uh, without type annotations, just like checking that the variable is a particular type or null or not. And I think someone is just gonna have the time to do it. Uh, eventually. I'm guessing by the end of this year, that seems like the velocity that the community is going through.

We already have people trying to rewrite typescript in rust and building these amazing tools to validate their types. So there's a lot more interest in the type system than there has been previously side note. I'm so excited about people, rewriting typescript and rust, and also sad because I don't think it's gonna be nearly as possible as most think it is.

The type system is so many edge cases and it's still growing. So, uh, there's a lot of interest in it. And I think that people are gonna have more and more fun side projects such as literally implementing type script in the type system, like type type script equals. And then it takes it a string as a generic and gives you back like type errors or a runtime JavaScript.

Justin: I mean, the biggest thing that would be really needed is just a tremendous, tremendous test suite that just like goes through all your educations and can really validate types of stuff. And I know that they do have a lot of tests in the typescript repo, but it's just like, you know, anytime you build some thing like that, like that's a significantly non trivial effort.

Josh: Yeah.

Justin: That would be cool though.

Andrew: on the, on the implementing and rust part. Yeah, I think it like a lot of people see it as like the same problem class as like SWC. It's like, oh, just rewrite, babel in rust. But it's like, that's kind of doing a much simpler thing. It's just taking one syntax and porting it to another syntax. It's not a whole language.

A whole language is a whole different class of problem than like a CSS thing, or like that a six to five, uh, equivalent.

Josh: yeah. Oh, what a throwback. I forgot. It used to be called six to five. Those were the days we had two new versions of JavaScript, not one a year. And yeah, the, the fascinating thing about one of the fascinating things about the TypeScript type checker is, uh, how impossible it is to document there's a, a similar tangentially related call that gets put out sometimes for, oh, we should have a type script spec.

But that's impossible. There, there are type script, as you said, has a full test suite and there are still constantly bugs reported on type script for the parser and for the checker, the checker is like tens of thousands of lines of code. Like that's a lot of code. So yeah, I, whenever I get a pull request into type script, I have to steal myself emotionally for the inevitable bugs that get reported on it from production code, because that's, the spec is incomplete and the spec is there thousands about thousands of test cases.

Justin: There a, a statistic that somebody released a while back about like the average number of bugs versus lines of code. One to 60 or something like that. I don't remember what it was or something, but like, you know, if you think of like, if there is some set scale, a code base on average has one bug, every X lines of code 10,000, a hundred thousand, you know, however many lines of code that you have, you can see the bigger it is, the more bugs that are gone, going to be present.

So it's like, you know, when you have a huge and especially complex system, like a type checker, uh, it's inevitable to, to, to face bugs so yeah, one of those things

Josh: I actually first interpreted that as the opposite ratio that it's 60 bugs per line of code, doesn't strike me as too

Justin: depends on how long your lines are. this is a, this is a good justification for shorter lines. You know, you can like bump those metrics.

Josh: unreasonable. Yeah. Oh yeah. those are rookie numbers.

[00:13:18] Josh's TypeScript Features

Andrew: Uh, what are some of those features that you did get merged into typescript?

Josh: Ooh. My favorite one is the most recent one. Honestly, I feel like I've been doing publicity and conference stuff too much lately. I haven't really done much coding. I haven't gotten a PR merged or sent since the spring, this year, uh, the most recent one took three years to get merged because it was way too big of a pull request.

It was also kind of hard to explain without sounding too technical or like getting too technical. Uh, it's allowing code before the super in a derived class instructor in JavaScript. If you access super or this in a constructor of a derived class before you call the super that's not allowed because the base class hasn't finished initializing, you'll get a runtime error.

So typescript represented this in the type system is just not allowing you to touch those at all. It also said you can't run any code before the super, just to be safe. It was easier to implement, but like, if you wanna say console dot log before the super and a constructor that. That was also erroneously, not allowed in type script, but in order to fix this, it was a little bit of work in the type checker and so much work in the trans piler.

The thing that takes your type scripts and text and generates JavaScript, which hurts me because I don't even use type scripts, trans piler, I use SWC in babel or whatever instead. Uh, so I ended up sending that pull request while I think before getting employed at codecademy and then getting it merged, I think like, just before I left codecademy, like, it was almost a longer period than my most recent job.

Um, I almost sent them a cake, but the typescript team is all remote. So I just sent myself the cake. Instead, there's a tweet that I have, um, but more relevant for most users since most of us are done with like, oops in JavaScript and type script. Anyway, is I added Ts expect error, which is like, Ts, ignore it, suppresses an error, but it throws an error if you don't have an error anymore.

So like, why would you use Ts ignore, use my thing. Um, and I also helped

work. Yeah, that was me. You used that.

Andrew: wow. we talked about it last

Justin: is amazing.

Josh: oh

Justin: I didn't realize you added that. Holy hell.

Josh: It all comes around. Yeah. Um, yeah, that's, that's one of my favorite things. Um, I did that. I did some work on pretty mode with colors, which fun fact. Orta a former typed grip team member who I think you've, you mentioned also last episode, uh, is like redoing soon, which I'm very excited about and like a few other random, small things, mostly around bugs that I hit or features.

I wanted one writing typescript code. See, it's been a good amount. I wanna do more though. I wanna really get my hands in there.

Justin: Ts expect error thing. Huge. Uh, so for people who might not be familiar, so Ts ignore is, uh, a inline comment to say, Hey, ignore this type issue often when. Transitioning in a big code base and you're changing a bunch of types or adding a bunch of types. It can be a lot of errors. So Ts ignore used to be the thing, but then you forget them.

they're in your code base and they're like scattered everywhere. And you've got all these bugs that crop up because the type checker is missing thing. So Ts expect error, uh, does the same thing, ignores it unless there is no error. And then it errors, which is phenomenal because it like makes sure that you actually remove the check.

Uh, and I've used it a lot in migrations. So check out our, our last episode or the episode for this week, the type script migration episode. Uh, we, we talked a little bit about that, so yeah, that's amazing. I have, uh, I have much respect for you for that. That has changed my life. So good.

Josh: glad to hear. Thanks. It was actually not that big of a change. Um, I had to add some extra metadata inside type script, but once you get over the hump of, and fear of, oh my God, I'm working in type script. It's actually a pretty reasonable code base. And that the team's pretty supportive. They're nice.

People would recommend there's actually a feature from flow. I really wish they would add to type script, uh, where. Uh, flow lets you disable specific classifications of errors type script. Hasn't implemented an equivalent because they don't wanna implement per error disables because the errors change a lot.

It's not a stable API. It, it might never be. But generally I would like to be able to say disable or ignore it any sign of nor any assignability error or something like that. I don't know how that API would look. I don't know how we would classify if you had nested things or what, so it's still an open discussion, but I've noticed that people actually use Ts expect error as a form of testing for the type system, which is very cool, but also kind of imprecise that you just want any error to be thrown at all.

It's nifty.

Justin: I I'm on that threat in the TypeScript issues, cuz it was, it was also a thing for big migrations. It's like, look, I don't wanna ignore everything. It's like, there's this one specific error. And this is the only thing that we really don't want. And there's a error codes that are dynamic and, and they're like, we don't want the error codes to become like as an error code changes, this becomes a breaking change in your code base.

It's like, this is not a dependency that we, as the type script team want to have to worry about. So it is a hard thing. But yeah, that would be, that would be amazing.

Josh: yeah,

Justin: Maybe they'll figure it out.

Josh: fingers crossed.

[00:18:30] TypeScript ESLint

Justin: Uh, So you work on a lot of other open source projects. Uh, so you're also a maintainer on the type script eslint um, how'd you get involved with that? Uh, and, and if you had to give a spiel for why people should use it, what would you say?

Josh: Oh, boy, I keep forgetting to give the spiel. So I will give it first and then answer the first question. Um, typescript eslint is the tooling, which allows you to run type, uh, eslint on your typescript code. I like to say it's a beautifully evil SEO ploy, cuz it's not type script and it is not eslint. Don't mistakenly give me attribution for either of those projects.

It is a glue, but it's a very good glue and a very important, because even though typescript adds a lot of safety to your code, there's still a lot of things you'd want to check for with a linter like naming, like catching unused variables, more intelligently like bugs that we can detect for you, which I'd love to talk about later.

Um, I originally got started years ago. There was a project called tslint, which was like eslint, but for type script, uh, with a T instead of an E, so clever much better name, but tslint was less community run than type script eslint or eslint. It was also a separate implementation from eslint. It was typescript native rather than JavaScript native, which meant that whenever something good would come out for eslint we'd have to port it over to tslint in theory, vice versa.

But in practice, eslint was much more popular. Also tslint was largely sponsored and supported by palantir a company that got heavily involved politically with Trump. So that's not an association that you want. So a lot of people didn't want to get involved with tslint or didn't use it. Um, I was kind of hoping we'd spin it out, make it a community thing, but I be, I got involved with tslint.

Um, I think in the middle of it's. Life cycle. Uh, I just really like that area. Um, I went from, oh man, this is finding so many good bugs in my codes to, I wanna improve it to a maintainer. I was one of the last ones and then they killed it like almost immediately after I started or announced the killing of it.

So I helped kill it, which was very fun. And then I was a little burned out in part because I had a job and didn't have the emotional or practical time for, uh, open source. And also because I, I wanted to kind of do my own projects. So I waited a little while and then hopped on that type should be Islam project.

It's been a great journey. Um, I'm really excited. We only recently started doing a lot of work on the website and trying to get more funding and overhaul the docs. So I feel like the people who came before me like James Henry, Brad Zacker Armo I don't know last name are the other three, currently active maintainers.

They did an amazing job working with the esent team wholesale, setting up this great product architecture that. Lets you run eslint on typescript code, which is far more impressive technically than I realized joining the team. And now I'm really excited that we get to like really evangelize it, figure out the performance issues, add features that like really make it stand out as a great package.

That's also a spiel, I guess.

Andrew: Are there, uh, any cool or interesting rules that you've added to that code base that, that you just love?

Josh: Oh yeah. We've been talking about this a lot of like one of the, the banner headliner rules. What is it that we can go out there and say, Hey, you should work with this project, cuz this will find you bugs. And two of the rules that I particularly love are no floating promises and no misused promises. Um, I wrote, I think the original, no floating promises implementation in tslint someone else wrote it better in type script eslint um, that will find if you create a promise and then don't handle it in some way, such as returning it.

Dot catching it, passing it to a function as an argument, which catches a shocking number of bugs. And the bug might not even be a program crash. It might be that, um, you don't handle an error, so you don't log the error. So suddenly you, you realize one day that you've had like 3000 errors in production, which is something that, that has happened that I've been told.

Uh, no misuse promises is similar. It's if you pass a promise to something that doesn't handle promises. So like, uh, a really common one to be in react in other UI libraries that are JSX based. If you pass an asynchronous function as an event listener like on click, what happens if that promise throws after a second, like nothing will handle that, that, that those rules are a little more controversial though, because some people intentionally make floating promises and they want that.

Um, we also have a set of rules. I did not write these, but other people have, and I've helped them. Um, no misused, any or snow, et cetera, any like accidental, any calls and variables or arguments. Um, like for example, JS dot parse is typed as returning any and any, for those who haven't used it, first of all, good for you not using it.

Second of all, it's the type script Yolo type. It lets you do whatever you want, which is real dangerous. And even if you never intentionally added any in your code, some APIs return it. So our extra rules will help you catch when you accidentally are not type safe in your code, which is great. Don't use any, if you can avoid it at all, practically, which is not always possible, but you know, most of the time.

Justin: Outside of outside of these, uh, or this type script slant. Have you written any other type, script based tool?

Josh: Yeah. Um, I got my name on the eslint plugin expect type package, which was not written by me and I, uh, I'm just happy to be a maintainer on it. I've written some features. Um, I, the thing I'm most excited about that I am personally writing and leading is a project called type stat uh, it's really amusing to me to come on after the episode where you talk about migrating the type script, because that's what my project does.

It migrates from JavaScript to type scripts and can also migrate from type script to more strict type script. The problem is, is that's, uh, that's an unsolvable problem. It's physically practically impossible to do it right. But if you get people like 95% of the way there that's useful. And also what I've seen is I wrote this super advanced, like near best in industry engine for improving type annotations and converting code.

And what people really want for is renaming files to Ts or TSX, uh, intelligently, which is kind of hurtful to me that that's the usage, but I'll take what I can get. Uh, but once I have more time, I'm really hoping to continue working on type stat. We use it at codecademy in our conversion and it got us a lot of really good progress automatically.

So fingers crossed. I'll get to work on it later this year.

Justin: That'd be awesome. Big type or big type migrations and just big migrations in general is such a, I think, I feel like an underserved, like aspect of programming, just cuz you have things like this where you're moving from JavaScript to type script, which are not an unknown thing or moving from flow to type script or, you know, you have these migrations, um, it's good.

When you have a type system to lean on to sort of help you do it. Right. But yeah, the, we talked about it before and I've, I've picked it in some tool tips in the past, but there's this tool called better, uh, by a, I'm not sure if he's a current or former Spotify engineer that like helps you do big migrations and I don't know, that's always a really fun problem.

It's like interesting stuff that you can do there. So.

[00:25:57] Writing a Book

Andrew: Now let's move on to talking about the book. Uh, congrats on the release. Uh, if I was tasked with, uh, writing a book, I, I would just feel like I'm drowning for probably a year. Um, so congrats on actually getting it out. So, uh, what's the book about mainly and like who's the intended audience?

Josh: Thanks. I too had long periods of feeling the drowning, uh, it's called learning type script in line with the O'Reilly tradition of making a learning X language topic book for people who are not familiar with the thing or its equivalence yet, which is in contrast to the also excellence, uh, programming X series that O'Reilly makes where it's for people who are a little more advanced from a little more practical hands on, because they might also already have some experience in that area.

So learning type script is for people who may not have had programming language experience with types, like no type scripts, C sharp Java C plus plus, et cetera, you certainly can read it. And I think it still is a very good resource if you've worked in those languages before, but it does not assume knowledge of those things.

and, uh, another key, I think good thing about it is that it really focuses on building up your understanding of how to use and what is the type, script type system before delving into the deeper features of how it interacts with things like functions, classes and so on. Like what is a type system? Why is it that if you declare a variable without an initial value, you can assign whatever you want later on like how these shapes and object types, inferred, that type of thing feels like it comes naturally.

If you've been in a type language before, but if you haven't, then they're new to you. And also type script is different. It's a structurally typed language, not a, you know, compiled, static language like CPER Java. So the types actually have weird and surprising behaviors to people who are used to those languages.

So the target audiences, any developer who hasn't used type script yet in particular folks who haven't used too much typing language yet.

Justin: You you'd mentioned it earlier, how, you know, it's, it's sort of hard to, to go back and teach these things, especially with a, a lot of knowledge of the topic. Did, did you, how did you like test your explanations? Like, did you do anything to say, Hey, does this like, make sense? Is this, did you work with an editor or something to like help you through this?

Like, I'm just trying to wrap my head around. It's like, what is the process of making sure that I am not spouting techno nonsense to people? Like I have no idea what I'm saying

Josh: In your experience, do people in our industry spout techno nonsense often? Is that a

Justin: quite often. Yeah, yeah, yeah. Go to any talk about Kubernetes and

Josh: oh my God. yeah. Kubernetes and monads are two topics that I I'm sure are understandable by humans, but I have yet to PR practically understand them. And

Justin: there a joke about functional programming?

Josh: yeah, it's a burrito that, that makes sense,

right? Yeah. So I'll, I'll, I'll give an overview of the overly process because I think it's a really good process. Um, and I'll also first start off with how I personally think of like teaching, how to figure out topics. Um, my father fun fact, uh, was, and is a mathematician who happens to focus on graph theory, number theory, stuff like that.

He's very cool. Uh, very, really cute guy, also lovely individual. And he taught graph theory for very many years, uh, which almost made me not go into computer science as a stupid sign of rebellion. But one of the things in graph theory that gets taught is the concept of, uh, a search depth first or breath first search and graph theory sounds really advanced and fancy, but much like the typescript type system actually has a lot of really useful applications for fun.

One is that if you represent each topic that you have to teach slash understand as a point or node as graph theory would call it, and then all the dependencies as lines or edges between those points node. For example, in order to understand, let's say class implements interface, you need to understand classes and interfaces.

You can then map out all the topics you want to teach in your book as a graph, and then do a search on that graph to figure out what needs to come first. And inevitably what most people learn with the type script teaching is that you have to introduce the object type really early on, which is painful because later you have to say use interfaces instead, and that's a whole confusing thing, but you need to understand the concept of structural typing before you can introduce like advanced interface usage.

So like I figured out the parts of the book that I wanted to cover talking about, like, should we cover functions before arrays? And I can't re I can never remember which one we ended up with and like all these different major topics that you need. And what's also cool about this is sometimes you'll find out in this graph that there are these random edge nodes out in the middle of nowhere that have like, it's very long line of dependencies and they're not actually useful.

So they're worth being cut. And I think I, I almost cut function overload. And I had like a moment of faith weakening just before publishing where the editor said, no, it's too late. You can't remove them, but they're kind of useless for most post code. And I almost cut 'em so I'll pause there. Does that like, kind of make sense as an explanation before I go into O'Reilly things.

Justin: That blows my mind a little bit, actually. I've never thought about, like, I've never thought about teaching a topic necessarily in that wave. Like it's a, it's a graph of things. It was like Andrew and I talk about knowledge graphs, a lot, uh, and stuff. So it's like, you know, it's kind of it obvious in hindsight, but I don't know.

Andrew: It seems like you could take like a fresh obsidian vault just start writing articles and linking them and then go, okay. I got the whole book. What's the order. And then you use the graph to find the order. That's that's an interesting idea.

Josh: Yeah. Yeah. Side note, plus one to your obsidian, shout out. I've been using notion and there it's wonderful, but people keep saying I should switch to, or at least try out obsidian. It looks great. Uh, but yeah, uh, it's funny also because, uh, at codecademy, there were a lot of people who were like former teachers who then went to a bootcamp or some similar thing.

And for them, these, these teaching things of figuring out the order are second nature. Like of course, yeah. You do some sort of analysis on like, what requires, what, and then me coming in as a nerd, who's never learned like how to talk to people or that's a bad stereotype. I regret bringing that up. Like, as someone who's never taught, like I come in and I'm like shocked at how cool it is.

Let's apply graph theory. But yeah. So the O'Reilly process is, uh, you first make a proposal for, what's gonna go in the book. Um, they have an idea of a subject that they wanna teach or you as a person they know, might. Uh, proposed one and you work with a development editor to figure out, okay, this topic is relevant and good.

This is why people are gonna like it. Here's how it's gonna compare to other books in and out of the O'Reilly family. Uh, then you spend a year or more writing this book where you have technical reviewers. I had more than the average number of them because I'm paranoid and neurotic. And you also have a, like a production editor, uh, or sorry, not a production editor, some, some kind of other editor technical editor who is both an English person master and a comp sci programming master who reviews your book as you go along.

So there are a lot of opportunities for people of various backgrounds and such that you can bring into like, be a tech reviewer on your book and give you early feedback. Um, I'll also say that I, uh, I. I put the book online, as I was told very early, they, they give these really early access previews of the book.

Like as each chapter is written after the third or fourth, it goes on their website for O Riley subscribers. And I'm still bitter about this. Someone back in April when the book was like two thirds of the way done, or maybe it was March posted in, oh, it's not done. I don't like this, like negative review on the platform.

And I was so upset by this. It really hurt me. It was like the first written review and it's, it was wrong. It wasn't done, but yeah. So there was, there was a lot of opportunity for early feedback. There, here.

I'm getting all emotional here

Justin: Well, that sounds like an O'Reilly messaging thing that they need to work out there. Right.

Josh: probably. Yeah. Make me feel better. Ooh.

[00:34:06] The Good Parts

Justin: well, speaking of feeling better, uh, what is the part of the book that you feel best about, or that you're proudest of?

Josh: I really like how the book introduces, um, object types and structural typing, I think in general, the first part of the book, the like intro to theory, the stuff plays really nicely. It's the part of the book that I thought about the most and put the most effort into, um, part of, part of that is that it's really hard to find good code snippets when you haven't introduced language features, like how do you introduce the concept of narrowing or like type script knows that if you like, say if type of something is string inside, that if statement, the things type is definitely string, even if it might have been like string or number ahead of time, like, how do you introduce the concept of union types, which by the way, is a prerequisite for an narrowing, uh, with when you don't have functions or arrays or classes or object types or anything.

So finding good code snippets and explanations for that area was really, really hard. And I'm really proud that I think we actually managed to do it. I'll also say within that, uh, the code snippets are almost all themed. Like each chapter has a different theme like actors or scientists or something. And unlike the vast majority of books in this industry, the, the gender skew is not majority male or male presenting.

It's like actually mostly women non-binary pardon me, women non-binary. And I just shocked that no one has done that before that I could find like it's very rare.

Justin: I'm glad you did that.

Andrew: Uh, does the book come on, come with any hands on projects? Or is it all text?

Josh: The book itself is I'll text, but at the end of each chapter, I yell at the learner to go to learningtypegroup.com slash the name of the chapter, uh, because there are a bunch of projects on there which each of which have a really annoyingly, cute theme. I've been told that it's perhaps too cutey, but, uh, the project.

The projects are there so that you can exercise the stuff that you've learned in that chapter. Um, I personally work best when after each chapter I take a break. I think about it. I digest it. I like reread the skimming and then do some sort of project. So I highly recommend people reading my book or any other book.

Definitely do project work. As you read through the thing, don't just read the book and then eventually work in type script. It's it's not how the human brain works for most people.

Andrew: Yeah. That's, that's something that like, even as a person who's like, I guess moderately advanced in type script, I, I wish there was a place I could go that had like type challenges to like help me, help teach me the type system a little bit more. I know there is the repo type challenges, uh, but it gets so hard so quickly that it just like, Ugh, like I tried to, I tried to do that in like a, uh, we had like an open office hours at intuit for type script.

And we tried to work few few through a few of them live and it just quickly went off the rails of like, oh God, I don't know what's happening. I swear. I'm an expert.

Josh: That's so funny. Maybe, maybe that's an opportunity for you to contribute. Maybe file an issue, ask for more beginner, intermediate, which by the way, I will note it is another learning of mine that the words, beginner, intermediate and advanced are like really damaging and negative for a lot of people. Like someone sees advance and they think, oh, that's not for me.

I could never learn that. Or they see beginner and they think, oh, that's below me. I won't read it. So whatever equivalent of those words that I've get to find, you could write more.

Andrew: Uh, what are some of the cutesy examples of the projects? Uh, do you have a favorite project that you included?

Josh: Oh boy. Um, the first one is that people write is the typinator. You're going back in time and, uh, you need to, you need to refactor a project, uh, using. I think it it's, this is, this was hard because it's the chapter that introduces the history of JavaScript and why text script was made. It doesn't introduce any type script to text.

So it's just, you're refactoring things to be modern JavaScript instead of old, you're the typinator uh, I was proud of that one, both because the silly name and because I couldn't think of what to put for the project. Um, there's one later on, uh, I'm like loading the site on my own computer. Oh yeah. Um, actually the second one, I used my best ideas first off to hook people in called system of a clown where, uh, the, the context is that you wanted to make a

I can't say it. Oh God. Pardon me, the, the context is you wanted to make a, an elaborate surprise clown themed party for your best friend, which I've always wanted to do for someone. It cracks me up so much. Uh, but then they, the clowns found out your code and removed or messed up all the type annotations in it.

So you have to go through the code and it's all like clown quotes. I don't know if someone's afraid of clowns. They probably would not enjoy this project, but there are no images. It's just text

Andrew: you definitely should check if the person is deathly afraid of clowns before giving them a surprise clown party.

Josh: Yeah. Yeah.

Justin: best surprise. Depends on who the surprise is really benefiting. Right?

Josh: It it's, it's very shakesperian. You know, someone is very upset and probably dead at the end of this party, but which actually brings me to my, my next favorite one where there's a, like a Shakespearean, uh, themed project later on, uh, oh, what was it called? Type spear. Yeah. Everyone is a iambic pantameter description.

They're like different steps in the projects.

Andrew: Oh, man. Yeah,

Josh: Which actually brings up to an interesting theory of projects. I think that, uh, some people work better when you have like little small challenges, which I call appetizers. It's like two to four things just to work on in, in series that you don't import code between each other.

And some people prefer larger projects, or personally, I prefer to do them in that order. So the projects are separated into appetizers entres and desserts where appetizers are small entres are big and desserts are like cutey appetizers. Oh, sorry. Cutey entres

Andrew: yeah. If anything, you come up with some of the most interesting type script challenges for yourself and for your, your readers. I appreciate the

Josh: Thanks.

Justin: Yeah, it sounds like he had fun with it, which I think is important, important part of any long journey like this. Hmm.

Josh: Yeah, that's a, it's a good way to avoid burnout where if you're not having fun doing it, you're gonna burnout way sooner. And for me writing these projects, which were, which are difficult, like finding a project that only uses the syntax features and concepts thus far introduced and having a good theme.

It's hard. So that definitely got me through it.

[00:40:44] What's Next?

Justin: Do you have any plans to write another one?

Josh: Oh boy. I'm gonna wait a little while on that one. I have been talking occasionally with other authors on like collaborating on a book or doing a second edition. And I think I would like to, I would like to in part, because I think there are a lot of good topics that could be explored in book form. I might also explore doing like a udemy or some video thing or something, but, uh, it's gonna be a little while before I'm ready, willing, and able to take on a book again like this, this one I did, um, while full-time employed for most of the process and only the last few months were when I was already like an open source maintainer and it took a lot out of me.

Like emotionally and time and opportunity cost of other things. Are you too, I'm curious, actually, you can cut this if you want, but are you too planning on writing any books? Any interest

Andrew: I, I don't think I, I have the, the after work wherewithal to do that. Maybe if I had nothing else going on, I'd write a book, but, uh, my open source efforts have shown me and the people around me that I should probably not work in my non-work hours.

Justin: I think I would struggle to write a book.

Andrew: Um,

So are there any like, uh, yet to be implemented type script features that you've been following in the repo that you're just dying to have? Like, you're like, oh, I wish I had this now, but just hasn't been there for years.

Josh: might not be the most user applicable. But it's super important, a type assignability API as a consumer of the TypeScript APIs, like import to yes, from type script in our JavaScript type script files. There's no good way to determine whether some piece of code some object or value or whatever is assignable to another things type.

Whether two types are equivalent or one's assignable together or whatever. And yeah, this is, this is like, uh, this is a consumer in TypeScript eslint,, or type other build on project spaces and not something running TSC would care about, but it would be so nice for lint rules and migrations and analysis tools altogether.

If we could have an assignability API, um, like we, there are so many lint rules that I would love to write. That would be super useful for people. Like if you have a type assertion detecting whether the type assertion is no longer valid or necessary, or whether a type annotation, not a variable is. Like losing type information.

These, there are so many things that we need a type assignability API for, and we just don't have it yet. There are some efforts. Um, there, I forget the name of the package. Um, shoot, there is a package that like re basically re implements the type checker, uh, simple type. I think the name of it as I'm looking it up, uh, but like it's not, oh yeah.

Ts simple type. It's a great package, but it's not type script itself. So that means you have to take on a dependency of a reimplementation of part of type script, um, in type stat. What I do, and I hate this, this, this really kills me is I I, uh, Fs dot write file or fs.read file, and then write file your type script JS file on dis to modify the text of the type scripts code to export the type checker type assignability APIs I need.

Uh, don't do that. I didn't even use the like standard rewrite JS, whatever packages, cuz I don't want people copying that approach. Stupid and terrible, but until type script has an API, what else are you

Andrew: that's something I I've found too, is that I wish like type scripts. API was a little more usable in some cases like I've done a lot of work on, uh, like react prop type generation doing this. And, uh, I had to end up resulting in using like internal APIs and I had to put Ts Ts, uh, ignores in my code. But yeah.

Stuff like that is, is definitely something that I would want, but it's also like a non-trivial problem too. So like with type of assignability, like what if it's a generic like that, that, that always throws a wrench in things, especially with like the react prop types. it's like you want static props and then, oh, Nope, this is generic.

And that has a cascading order of, of effects.

Josh: There's one the, the most like seriously advanced stuff that I'm proud of in type stat that I'd love to port to linting rules is determining whether types. Either have not enough information in them or too much. Um, like let's say that you have an interface that's used in a bunch of places in your code, and you're you think some of the fields on that interface may no longer be used?

How do you determine that? Well, you could find every value that's ever that interface type and see whether it has those fields and whether they're used. So you can go through your entire code base and develop this counter of like all these times the fields are used and it would be so nice to be able to use typescript APIs, to like construct a new type and to check assignability between them.

But yeah, it's hard. I too have done that and I hope you use Ts expect error for those not ts-ignore!.

Yeah. I also, I would love type script to basically onboard the Ts error translator website, um, type scripts, error messages are technically accurate and precise. Which means that for very many more complex error messages, people just don't understand them, which is unfortunate and inevitable. But if you look at what, like rust does, rust errors are amazing and beautiful.

So I'd like to see now that type script has like really good precise error messages. It would be nice to have a level beyond pretty like, uh, I don't know, pretty or, or something a term that's not already used.

Andrew: Or Orta did an exploration in just like adding a bunch of white space into the, the errors. And I'm kind of sad that that work never landed. Cuz I thought it made the errors a lot more readable.

Josh: Yeah. I would love it. If someone just wrote a wrap around TSC that messed around with the air, that'd be cool. Get order on here. Maybe might be where it'll do it.

Justin: Yeah. Yeah. Uh, it would, it would be nice. I, I think that like a lot of times some of the issue is it's like an error occurs deep in the structure and it's like one, one property of this object that is different. And they're like incompatible for certain reason, you see this a lot in like react props and it becomes this thing of like, I, I get just lambasted with this giant tree of stuff.

And I'm like trying to find it's like, okay, where in this tree is something wrong? Um, like, like me can be kind of hard. Yeah.

What is a recent type script feature that's been released that you just absolutely love?

Josh: They did a lot of work on recursive, conditional types and conditional and inferred types in general. And this is near and dear to my heart. Not just because I've made a name for myself, implementing binary, arithmetic, and other shenanigans using them. But also because, uh, we , there are a lot of really, really important things that you can do with a strong representation in the type system of a complex system.

And one thing that I'm really excited about is the set of advances people have been making in design systems. I promise this will all make sense and link together soon. Uh, there is a lot of work going into not just tailwind style, basic primitives, but having design systems where you as the consumer don't specify things in terms of background color equals blue 500, you say background color equals whatever background, light, primary, or background secondary or something like that.

And having a fully types safe site, having a fully type safe API for those types of things where you can specify these variance tokens, and then variance of your, uh, components is extremely difficult in type script, because you have to be able to specify the entire CSS type, which is the big type declaration for CSS, uh, and then also any variance for a component.

And then also allow list or deny list, different props that people have configured for a component. And then also you have theming in there, like some subset of the application has extra colors because there are fancy thing of their own. So I think now that type script has really good conditional and for template literal, et cetera types, being able to strongly type your design system tokens and things like styled system and stitches is incredible and will be very beneficial for front end developers.

So yay type script.

Justin: if we can only get typed children, we'll. In such a better world, more of a react type script combinational problem there, but ah, one day, mm.

Josh: I'm still bitter that the definitely types types for react. First of all, that they exist that react doesn't have its own TypeScript types, but I understand, you know, they're not a TypeScript project on their own. And then also that react, there's this bizarre edge case that people haven't been able to figure out of the types where react dot react node, the type, which is the general type for react, children doesn't allow.

What is it like? It doesn't allow a raise or fragments, or it doesn't allow a raise or something like this. Like there's this one random edge case that for some bizarre bug reason does not con is not considered assignable to react node. And it means that like, if you use react at FC for a while, you had to wrap a raise in a fragment, like it's just like little pedantic thing that shouldn't matter.

And it's confusing to newcomers, but it has an easy work around if you know it.

Andrew: tho those are some difficult types to read the react types, ver very, very generic, but I'm sure it's, it's easy for you with your all your, uh, type system gymnastics. Yeah,

Josh: That's that's really funny. No, it's, it's horrifying and difficult. And I resent the world every time I have to do it. I'm good enough at type system gymnastics to learn it when I need it. But I don't think there's any human on this planet. Who's really good at reading. Nested generic, conditional types.

It's impossible. It it's just not something that the human brain was made for. And it's not something that you should have to do frequently enough to get good at it. If you have complex types like this, your code is, is gonna be unreadable. Like that's not a system that you want anyone to work in.

Andrew: very true. Okay. With that, let's move on to tool tips.

[00:50:57] Tooltips

Josh: I would like to share something that I have started recommending to people type script, error, translator, or Ts error, translator by a person who's named Matt Pocock uh, it's awesome. It. Takes in your TypeScript error messages and gives you a much more human readable version of it. It's Ts error, translator dot vercel dot app.

Uh, it's not, I recently tweeted at it. It's just a really nice exploration of how can we format TypeScript error messages in a more humane way for people who need more friendly and less technical accuracy and precise. Also, the website's a really good user experience study where it just has the title and then an example, error with a button to submit it.

And that I just, I really like the practice of having web apps where there's a very clear call to action and, and very low barrier to entry. So nice job, Matt.

Justin: lot of really good types of script content recently, too. He's also. Relatively well known for working on X state, doing a lot of really cool work there. So,

Andrew: Yeah. Tools like these are, are, are great for all swaths of people, but especially for beginners where like typescripts type errors can seem like a very high wall to overcome. Like something I found at as I was learning programming and trying to teach to others is that errors in general are just like very hard for you to parse it first.

Like, you'll see an error and go, God, there's an error and not read the error. Took me like years of programming to actually go wait, I should read that error.

Josh: Yeah, it sounds so simple and almost derogatory. Oh, why didn't you read the error, but it's such a true thing that people instinctively don't read the errors. They're intimidating and scary. I, I still struggle with this. Yeah, for sure.

Justin: I think it's, it's broadly just a conversation around errors, themselves being an underdeveloped part of our user experience. I mean, I. For so long, they've been treated as just what they are like a, a, a thing that happens occasionally that is the unhappy path. And, you know, you wanna give enough information for somebody to move on to life, but it's not something that you're focused on, cuz you're building something else.

Hopefully your library or tool or website or something does something. But you know, the errors, especially in our tools are such an important part of utilizing the tool that like, I think languages like rust are really showing that if you treat errors like a first class user experience, it really changes how people interact with the language, uh, or the tool.

So yeah.

Andrew: Yeah, that's, that's one of the things that makes me really excited about, uh, the Rome project is that like, they seem to be focusing on errors as like a first class user experience. So they have like the, almost the industry standard of errors. It tells you what's wrong. It tells you how to fix it. It underlines the exact place where the error is going on.

So, uh, I, I really hope Rome gets over the finish line one day.

Josh: People have been talking a lot recently about ages of things like swyx's talk about the third age of JavaScript is very spot on and very good. And I think that we're starting to get into very early stages of maybe a fourth age of dev tools. The first one was just getting dev tools in the first place like them E backs.

And so on. Then we had full on gooey ides, like visual studio and eclipse, and remember Atom, that whole thing. And then the next phase was actually Atom and vs code. These lightweight editors that still packed in a lot of really good features at a user friendly level. And I think the next thing is gonna be stuff like Rome and Ts error translator, where not only do they have lightweight good editors with good user features, but they go outta their way to assist users.

We're not assuming, you know, a plain text output is acceptable. We need colors and syntax highlighting and like pointing at the right line type stuff. That's really huge.

Andrew: Okay, I'm gonna share something that we talked about in our most recent episode, but I just started re using it, uh, heavily at my job. Uh, JS code shift, uh, JS code shift is a tool that, uh, allows you to write transforms that run in your code and allow you to transform something to something else. What I've been using it for is we've been organizing our monorepo a little bit better.

And with that comes a lot of changing imports. Like if I were to have done, uh, the work by hand, it probably would've taken me a few days to update all the imports in the thousands of files that we have, like probably weeks even. Uh, but with JS code shift, I was able to write like 300 lines of code that, uh, Transformed my imports from many imports to different files to imports to one package.

But at the same time, create an index file for that package that goes, oh, people are importing these things. I'm going to make an index file that exports those things. So I had to do almost no work. Like I started doing it, uh, by hand and I got two hours in and I'm like, this is not sustainable. Then I ran the code mod and it was like, my index file was literally 500 lines long.

And I'm like, thank God. I didn't write that.

Josh: that's

Justin: usually called like barrel files or something.

Andrew: I've never heard that name, but it could be that

Josh: I call 'em Windex files because they're a good win for use of building. Just kidding. I've never used

Justin: They have a name for those.

Josh: but that's, that's beautiful, honestly. That you were able to use code shift JS code shift to save yourself so much time. I think AST analysis and asst migration mutation stuff is an underappreciated skill. Like there are so many people I've seen spend so many days, hours cycles doing manual migrations when learning JS code shift are similar.

Would have both given them a better understanding of the programming languages they're using and net saved them time. It's a win-win.

Andrew: Every time I use an AST, I'm like I programmed, I did it today.

Yeah.

Justin: AST Explorer is probably one of the best tools I've just ever used hands down, Josh, you were talking about like, uh, a simple site that does a thing that has like a pretty clear call action and clear purpose. That is like one of those apps that like. The, the amount of value that thing has provided me over the years is just, is extraordinarily high because anytime I write a code mod for anything, it's like, I go to AST explorer.net first.

It's like, that is the first place where I do anything.

Josh: Yeah, same. I mean, I am a frequent heavy user of AST Explorer on net. I would also actually encourage you to try out typescript-eslint.io/play. We don't want to compete with anyone, but, uh, we're making a playground. That's very similar to AST explored on it, but tailored for working on linting rules and type scripts eslint so, um, although we don't have nearly the support for various languages, they support like markdown in variance and all this random other stuff.

Um, we are, we are trying to make it really good for specifically like people who are writing lint rules or AST mutations based off of eslint, which by the way, actually is not that bad as a, as a mutation tool. Like, um, I was helping someone recently switch from style components to a like, Style system like API and we were writing eslint rules with fixers and some of the, some of the rules were basically just migrators akin to JS code, shift, fun stuff.

Justin: So my first tool tip is actually a product. I discovered it. We talk a lot about tools here, obviously. Uh, it's this product called interval it's interval.com and it's a tool for building internal. Internal tools. Uh, so there's a lot of products in this category, but the thing about this that's really interesting is they give you a really terse API and you just define some functions and, and like this flow that happens in this object and this API, and it generates a UI for you just based off of that, just a little bit of configuration that you provide.

And we're talking about like pretty simple basic forms, but there's a whole like workflow. You can sort of coordinate things and you can do authentication and all this stuff. So it's like, if you need to do a task, if you need to write a task that like somebody needs to, to do semi-regularly, whatever that gives you the ability to do that, um, the product is really interesting, but this idea of like simplistic code generating UI to help someone complete a task is also something that I think is really compelling.

So like the idea looked interesting, thought I'd share.

Josh: they have a

Justin: I do it's really well done.

Josh: great homepage. Yeah

some of my favorite projects in the past have been working for internal tools. Like it's so much fun writing for like a customer support team who you can talk to rather than angry customers or angry B2B clients.

Andrew: Yeah.

Josh: My, my next tool tip is a book called laziness does not exist. I read it recently on a team member's recommendation and it's fantastic. The, the title has shocked some, but I agree with the books hypothesis and, and teachings that a lot of us feel this extreme need to always be producing capitalism, rah RA.

And if we take some time to really evaluate what's important to ourselves, we'll be a lot better for it. I personally struggle with always feeling a need to be to, to produce. Uh, and I have a hard time sitting down enjoying things, smelling the roses as they say. So just a simple act, like having a macchiato and donut or something in the morning.

I, I, I find it hard to really enjoy it, but this book is really helpful there. So highly recommend to all those overstressed burned out tech workers, open source maintainers, et cetera. It's a great book.

Andrew: My last tool tip for the week is a command pallet component. Uh, so there's a few of these out there, but I think this is probably the only accessible one. And it's really pretty. So a command pallet for those who don't know is, uh, modern applications usually expose this where you can hit command K and it opens up a spotlight like Explorer, where you can run various commands in an app.

And this is just a component that makes it super easy to add that type of experience to your app. Uh, I use the same pattern on my, uh, personal website for my digital garden. You, uh, navigate it by using a command pallet menu. So, uh, if you're looking for an off the shelf component that does it for you, uh, react dash command, K w would be a good bet.

Josh: for the recommendation.

Andrew: in a very pretty website.

Justin: These Components are actually really hard to build command palette. Very hard. There's a lot of interactions that goes on here. The scroll behavior is very particular. You know how all the filtering works, how you hook up to the yeah, lot that goes on this one's gorgeous. Love it

Josh: And you said it's accessible. That's even more impressive. Like these are hard to get rights.

Andrew: Yep. It said somewhere on the homepage.

Are y'all

Justin: using this for descript.

Andrew: uh, no, we have a custom implementation. Uh, I think, I think this is a pretty new project for, uh, looking at the commits

Justin: Cool. Well, speaking of obsidian, my last one for today is this really, really interesting project. Uh, it's called local rest API for obsidian. So essentially it is a plugin that you run that gives you a local host rest API for your obsidian vault. So if you want to build some tooling, uh, to just do stuff with your notes or to create notes, to read stuff from your vault or whatever, but you don't actually want to go through the, the hassle of like building an obsidian plugin to do all this stuff.

You can install this plugin and it gives you rest API, and then you can. Build your tool and whatever, in bash or whatever you want, you know, to to go through and, and do stuff, find notes, create new things. It's great. It's simple. Uh, and yeah, I've enjoyed it. It's like a good way to write some, like I wrote some Chron tasks to go through and to create some summary notes and I do it through this and it's been good.

Andrew: That's interesting. What do you summarize?

Justin: So I group up like meeting notes from different weeks and like kind of put them in a summary. And then I have like a special tag that I'll highlight some things with with important or whatever. So I'll have a, a, like a roll up of, of important highlights for the week. Uh, yeah, it's good.

Josh: That's so smart. I should do that.

Andrew: okay. Yeah, that, that, that's pretty cool. Uh, I never got over the hump of actually taking the notes, so I, I still have a while to go before I can use to like this. Okay. Uh, and that's it for tool tips this week? Uh, thanks Josh. For coming on. This has been, uh, a very interesting talk. Talk about all things type script, and I wish you, uh, good luck with selling your book.

Well,

Josh: Thanks. Uh, I really appreciate you folks having me on this has been a dream for a while. Please buy my book, read it. Five stars, sponsor me on GitHub, like, and subscribe. I also Twitch stream code things. Yeah. Thanks everyone.

Justin: Yeah, thanks, Josh. It's so great seeing you again. It's been forever, so it's lovely to have you on.

Andrew: that's it for this week's episode of dev tools, FM, be sure to follow us on YouTube and wherever you consume your podcast. Thanks for listening.