Hey there friends. So yesterday I was just a fanboying I guess about Prisma. If you haven't heard of Prisma, it is a Oh what does that? It's ORN, I can't remember what what the word for that is but it interfaces between you and a backend database. So it supports post-grass and SQLite my sequel and a MongoDB support is coming. So yeah, just so you have a database and you tell it what database what kind of,Database you're hitting and how to connect to it or what the connection URL is. And then it manages connecting to it and you have the rest of your code doesn't have to worry about what type of database it is. You just work with Prisma. And what makes Prisma especially special is that it has a really great way for defining your schema for the types or the models that your database supports. It has a really nice way of making the database match that so it'll create the tables for you and everything. It has a great way for my great.Hitting so if you need to change the column name or something then it will automate that process and and that can be part of your deployment pipeline is to alter tables to add columns and stuff like that. It doesn't quite help you with like breaking changes. It they have some articles to help, you know, how to go about doing that and I have successfully done that with Prisma. But yeah, and and it's it's not like a terribly difficult thing to do necessarily but I mean if it's a really great big breaking change then having zero downtime is tricky. But yeah, I've had a couple like the situations where I needed to remove an enum value and stuff and I was able to do that without too much trouble. Thanks to a lot to prism as migrate feature, but then the thing that you experience on a regular basis working with Prisma that just I love is its type script support. So you define this schema and then it generates TypeScript types. So that as you're using Prisma you say Prisma dot and then the,The table that you want to get and info from and then find many and then you have a select and aware and an order by and if there's relations so like a user has many posts or something then you can get all that users posts or if you're looking for posts, you can get the the author and data from that and it's all just so nice with TypeScript. It's it's brilliant. So if you are using one of those databases and you haven't tried Prisma yet give it a look it is fantastic. I'm really really happy with it. Hope you're having an awesome day andWe'll talk to you later.
https://github.com/johnlindquist/kit/discussions/310 https://www.scriptkit.com/ Hello friends. So this morning, I finished something that I was working on a little bit yesterday. It's a script kit script to call Cloud Nary upload which allows me to very easily upload images to my cloud nary account. It uses the cloud nary API and yeah, I just need a couple of environment variables and and you can use this too. You get script kit, you can copy the same script. And yeah, you just need a couple environment variables and then it uses the script kit. UI which is basically kind of like,Spotlight or Alfred where you say I want to run the culinary upload and then it asks you which folder you want to upload it to and it gives you this way to navigate around those so you can say on the current folder. I want one folder one directory yep or I want to go into this directory and so you can kind of navigate the folder structure of cloud nary which is really useful for me because I know that I could just like throw all of my blog post images and all of my epic react article images and all of my other images throughout my site into one giant bucket andReference those URLs and whatever but I don't know about you I just really like to have things organized and directory makes the most sense. And so, you can navigate around the directory as you would expect. You can create a new directory and I also cash the other folders that are within a directory so I don't have to hit the API every time you go you're as your navigating around. And so I give you an option to refresh the cash for a particular directory. And and yeah, and so once you've selected your directory, then it gives you a drag and drop little UI where you can drop as many images.As you like and then it goes through each one of those images and asks you what you want the name of the image to be it gives the default for whatever the file name is And then yeah and then it'll upload it. And when you're all done, it will open up your browser to show you to the directory that you chose so that you can see all the images. It also copies the URL for each image that you uploaded and so if you have if you're just uploading one then that's the one that's in your code board. If you upload multiples and they're gonna overwrite each other, which is why I think it's really good idea to have a clipboard history with Alfred is is how I do that. And so yeah, I just updated.My 2010 decade and review posts in their like 20 images in that post and I uploaded those all of those and updated the blog post in like just five minutes. It was really nice. So eventually, I'm gonna automate the whole process of putting all of my images on cautionary for all my blog posts, but this was a really good first take it what it's gonna be like for writing new blog posts and uploading new images. So anyway, this is another example of where script kit is awesome. I'll put a link to the script in the description and I hope that's interesting and helpful. Have a nice day.
Hello friends, so I wanted to talk today about whether or not you should make a custom hook for everything. So a few days ago, maybe last week there was this thing going around where people were recommending that you never ever use the react built-in hooks inside of a component, you always extract it to a custom hook. This is terrible advice. Don't do that at all. So the way that I think about hooks in React is the they're basically functions that have the,Only special distinction of being functions that actually call other hooks. That's the only thing special about them. So everything else about this function is the same as regular functions. And you don't make a function for every line of code that you write right? Like that would be ridiculous. The reason that we make functions is to encapsulate certain logic. And most of the time it's useful mostly for reuse. Sometimes it could be nice to take a bunch of chunks of code. And logically put it together so that it can be separate from the rest of our our code, but you've got to keep in mind that every single time you abstract something into another function you're adding complexity. And now you have to pass parameters and and maybe you didn't pass enough and so now you need to update those in the except the additional parameters and and and then if you're doing TypeScript, you have to make sure that you're typing for those parameters is correct and and potentially worry about the return value and then oh what if now weDecide that there's some logic in this function that says never mind let's return early or let's throw an error or something like that. Now, you have to start worrying about the consumer and say, oh well, they wanted to return early from here. So, I'll return early. It just gets to be more complex. There are more things to think about. So you can't avoid adding complexity when you start abstracting things into functions. It's just the way that it is it always adds complexity. Now whether or not it makes your code simple or more simple.Is a different matter or sorry let me say that differently whether or not it makes it easier for you as the the writer of the coder and the maintainer of the code to understand what's going on. That's a different matter. But the fact is that it will always increase complexity to extract things into separate functions and that is no different with hooks. This is especially relevant if you wanted to abstract just the use effect part, but you want to pass in some sort of function that's going to get called within that effect. That means that you'll either need to.Call back that your passing in or you have to use the latest ref pattern to always use the latest function. So anyway, hope that helps.
https://stackoverflow.com/a/46780568/971592 Hello there friends. Sorry, it's been a little bit of a break but I was working on something and I wanted to measure how fast it was but yeah and so I'm gonna use the Chrome DevTools profiling performance tab to profile it. And it's always so frustrating to like try and find the part of the code that you're trying to profile in that flame graph. It's really kind of a confusing area. And I remembered that there's the performance mark API and so you have the ability to add your own custom timings and so,You can say okay here's the start of what I'm trying to measure and here's the end. And how long did all of that take? And you can do like performance down now console log in and then like compare and stuff. But I wanted to look at the flame graph. And so I it didn't work right away and I looked up and found a stack overflow post that showed exactly how to do this and so I'll link to that in the notes of this episode. But basically, it's a combination of the mark and measure APIs on the performance object. So you say performance dot mark and you give it a string to label that mark.And then another performance you do whatever it is you want to do So in my case I wanted to measure the reading time of a blog post and I'm using this module called reading hyphen time, which I think is what like all the gaps people logs and everything used for this. And so I call that function and I'm on a really big blog post and to test this out. I call that function and then on the next line you say performance.mark and you give it another label and then you say right after that performance dot measure and you give three arguments the first is the label for. The measurement the second is for the start marker So whatever you put for the first performance dot mark, that's what the second argument here. And then the last argument is whatever you put for the end. So you give it a name and then the start in the end and then that will show up in your dev tools in the performance profiling tab and it just makes it so much easier to make sure that you're honing in on the area of the code that you actually care about. Unfortunately, I don't know whether this works very well for asynchronous code. So, I cure it's we're gonna do an await here and then afterThat away I don't think that's gonna work very well But for synchronous code it works great And actually if we're talking about async code and there is some performance profiling metrics that you can do with React app specifically and they do have the ability to do some sort of timings for that with asynchrony. It's actually very cool and I teach you about it on epic react. So if you're if you're not done the performance workshop yet, or the actually the performance section of the bookshelf app, then you may not have run up against that. But it's really cool. All right, hopefully that's helpful. I'll chat with you later.
Hello there friends. Welcome to June I am thinking about Postgres and Prisma and that sort of thing a lot lately because I'm working on my website and doing that sort of thing and one tip that I have for you if you ever do database sort of things is try to make sorry to make your data as. As restrictive as possible. Early on as as you're trying to make things. So like make things if you're like, I don't know if there should be a required field or not make it required. If you're this is an enum but we could have this we could have a lot of different values for this potentially have the fewest number of values possible to get you to the next phase. The reason is because it's a lot easier to later do a migration.That expands the permissive venous of that schema than going the other direction because when you go the other direction, you have to find all of the data rows that don't go into the new schema and update those so that they they fit. So, for example, if you have a first name field and you decide to make it optional first and then after you have a bunch of users you come in later and you decide no no this first name field needs to.Be required. Well, now you have to first go and update all of the usernames to be like unknown or something before you can do that schema update. And so yeah, just try to when you're starting a new project or when you're yeah, I guess not even a new project but when you're adding a new model or something like that try to be as restrictive as possible early and then you can loosen things up later when you have more context and you know, what makes more sense. So yeah, hopefully that's helpful and interesting. IIt's this is just personally affected me because I I was really loose at the start of this project and then I had to tighten things up and it's kind of annoying. So anyway, I hope that's interesting helpful. Ah, but a nice day.
https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render https://kentcdodds.com/blog/colocation https://epicreact.dev/improve-the-performance-of-your-react-forms Hello there friends. So today somebody shared a lightbri with me and I assumed that it was just a library to help you track rerenders. But it turns out it's like a state management library and that helps you avoid rerenders but my initial reaction and thought about tracking re-renders is the tools like that. I think lead people to jump directly to the natural and obvious solution, which is often not the best solution and I'm talking about memoization. So when,If you're tracking rerenders and that's how you measure whether something's faster or not you're gonna say, oh well this component didn't need to rerender so therefore. I will apply the re-render hammer to solve this problem and that is react memo. And then you have to use memo or use callback all the things that you pass to it. And that spiders in into the rest of your code base really easily. And so what I recommend is I have a blog post called fix the slow render before you fix the rerender and so you have to put a little bit more thought into it, but you find out what part of you. Here rendering is slow because even if you fix the rerender at some point you've got to render like there are necessary renders. And if those are slow then that's not a great user experience either. And so if you can fix that then maybe you'll be able to avoid needing to worry about rerenders. But sometimes you just there's nothing that's slow in particular. It's just a lot of things that add up to make the experience slower and so fixing renders is kind of the the best approach for that. And when you're in that situation, then I actually wrote.Another blog post called state look colocation can make your react apps faster and just recently wrote a blog post that takes an angle on the like forms and how you can use state collocation with forms and I'll link all of those at the top of this the description this episode. But basically, I think that we can get a lot by using state co-location also composability and composing our components, especially like layout components, so you don't have to pass.Props through all these other you know app components And as with a combination of the way that you structure things you often don't have to worry about unnecessary renders because they just can't happen. So anyway, the library itself was a state management tool and and some people get a kick out of that and that's great. That's awesome. I haven't found myself needing to reach for many state management tools outside of react query and went with Remix. I don't really need a state management tool. It's pretty awesome. But yeah, those are just some of the thoughts that I had when I first saw the name of this librarian. So hope that,Is interesting and helpful have a nice day.
Hello there friends, so I was thinking this morning about utilities and you know these little utility functions that we write and we put it in like a utils modular or something and sometimes when we're running these we want to split things out to make it just.Easier to manage or something and and it's just kind of a natural thing at least for me to want to split things out into individual files, so each utility is in its own file, you know, if it's just a single line or something. I typically just keep it on one but if it's kind of complicated or maybe there are group of utilities that make a lot of sense together. I just feel naturally inclined to move those into a separate file. But what I've found is in my experience is that you're often better off just leaving utilities all in the same file and thenMaybe using code comments or something to separate different parts of that file because what what I found happens over and over again is one utility depends on another and that utility depends on this other utility which depends on the first one and so you have like a cyclic dependency or cyclical dependency sort of thing and so when you try to start pulling things out into different utility or into different files, now you have to extract the other files. Or other utilities into separate files as well ultimately leading to basically a lot of files that have just a couple lines of utilities. And I definitely don't see that as being any simpler. And in fact, it can be even more complex when you start adding type script and now you have types that you need to extract it to different files so you can use them together. So, but there is a reason that we like to keep our files shorter and that's because when when you have a really big utility that can be really complicated. I,Worked on a a backbone view that was like 3,000 lines long once and it was not fun and I did not like having such a big file, but I've been thinking about this and I think that the problem isn't necessarily the size of the file the problem is the size of the the individual component. And so and just the number of concerns it was mixing. That was what made it really difficult. And so yeah, the the length of the file that doesn't really matter all that much. It's the number of mixed concerns that makes things really difficult. So, I would encourage you to. Think twice before extracting utility files or your utility functions into individual files and maybe first try to organize that file a little bit to make it easier to manage. I hope that's helpful and interesting have a nice day.
Good morning or afternoon or evening friends, I wanted to talk today about a saying that my wife has I think when my kids grow up they're gonna remember my mom always used to say this and and so what she says is we'll cross that bridge when we come to it now, of course this isn't like an original saying but she just says it a lot and what she's saying is that she doesn't want to make these decisions right now or use up the mental energy to decide whether or not. She wants to let the kids do a certain thing or whatever and I've taken to saying it myself, um and what I'll often say is if you want me to answer now, I'll just say no so why don't you wait until I'm able to think about this but it was I was thinking about this in the context of programming and that's kind of what doing calculations within an if statement or the right side of a ternary operator something that's kind of what that's like, so sometimes I will have a block. Of code where I'm doing some calculations and then I have an if statement that says if such and such then use the value of those calculations otherwise do nothing or otherwise do something else and so if you do your calculations first, then you're kind of crossing the bridge before you came to it you're making a calculation for a value for which you may not actually need at all if you don't end up going into the consequent and actually using that value and and so I get instead you put the calculation within the if block or what we call the consequent then. Then you're crossing the bridge when you come to it you don't actually need to make that calculation until you actually need to get that value now there are I explain this to my wife last night and I thought oh that would be a good thing for three minutes with Kenton and she said well now what are the situations in which you would ever want to do the calculation before, you know, you actually need it and I said well, sometimes it can be useful just for the way the code is structured you do all the calculations up here, sometimes it's easy to calculate one thing while you're calculating another thing even ifYou may not need both of those things and so there are reasons where you might want to cross the bridge before you come to it, but I I think in those situations you want to make sure that you're not ending up with a performance problem of some kind so mentoring can help out a lot so at the end of the day it comes down to readability and what's the most readable and then the exception is for those times where it's a performance problem then then you do things anyway just thought it was kind of interesting analogy or metaphor. Hope you're having a nice day, we'll talk to you later.
Hello there friends So this morning I was just thinking about this little tip that I share with you. It's pretty quick. In my global git ignore, which is located in my home directory dot get ignore underscore global. I have a couple of things in here that I wanted to shout out and specifically this morning. I was thinking about my ignored global good ignore. So I am I have a two rules that will ignore any files that or any directories that end in dot ignored in any files that include dot ignored dot in the file name and so what this allows me to do is very easy. Within the context of my project create a temporary file like temp dot ignored.js where I can script up a little things. I can require dependencies and require files in my application and whatever all within the context of the app and I can mess around kind of like a playground sort of thing to work on something until I have it solid and then I can take that code over to where it actually is. This can be really helpful when the feature that I'm working on is difficult to like navigate to or whatever the case may be. And so yeah,Or like it takes a series of steps even if it's not a UI thing if it takes a series of steps to get it to this particular state. Having a little file that I can use as a playground that doesn't have anything to do with get or whatever is really helpful. So yeah, the way that I do that is a star dot ignored slash and so that's for directories that end in dot ignored and star dot ignored dot star which will ignore any of the files that I included dot ignored. A couple other things that I have in here that sometimes people don't have. So this isGoogle ignore this applies to all of the get projects in my on my computer a dot ds underscore store and so when you open up a directory in in the Finder app on a Mac and creates this really annoying file and I still get pull requests from people all the time that included dot ds store and so I think I actually add that to my get ignore for each project as well when it's like an open source thing just to not deal with that. Also dot VS code. I know sometimes you can set like,Little local settings in there and so sometimes I'll force add those but by default. I don't want that in there dot idea for web storm and then you've got some like NPM and yarn debug stuff some VIM stuff in here with a star dots SWP and yeah anyway just kind of some helpful tips. I think the biggest one is the diagnord. I also have dot local sometimes. I'll put that in projects for like here's the dot EMV dot local, so it's just the stuff that's local on my machine. I don't want to commit that. Hope that.Helps. Have a wonderful day.
Hello friends so I mostly recording this one so that I can hopefully not forget it because I was working with doctor yesterday and I don't work with Docker a lot but I'm kind of thinking about in the next version of Epic React. I want to take the application that we build and make it even more real world. We're going to jump off of Create. React app and use Remix. Don't worry, they're probably going to have some sort of free tier or a trial version or something. So, I'm not going to force people to have a license to remix to take epic react. But I do want to teach you the the best way to build React applications andI think that that's remix and so it'd be a responsible for me to do it any other way. So anyway, we're going to be probably using remix and we're probably going to use a real database and this presents a lot of challenges because I'm here to teach you how to build React applications and I need to limit the scope otherwise it the course will be just enormous. And so I don't want to teach you how to set up a database and the easiest way to do that is to have you use Docker but then doctors and entirely different subject as well, that is also not easy. If you've never used it before I I'm struggling with it myself. But anyway in the process of I'm gonna try and like give you a bunch of scripts that you just run these scripts and and everything will work and that's the hope provided that you get docker installed properly. So we'll see hopefully that works out nicely. But my the thing that I learned yesterday or kind of today is that there I set up a postgres database inside a Docker container and I have a Docker composed file and I was following a tutorial and one of the things that had in there was. I guess I probably should have had this pulled up and ready for you it's Docker compose.Yeah, and it had oh I actually lost it had some like volume thing in here. And the and setting up the particular volume is basically where Docker is going to persist all of the data that is in the Postgres database so that when you close down the Docker container you can open it back up and all the data is still there. And I had a lot of trouble because I would try and delete the image delete the container and create it all brand new but it would reuse the same volume and so,I wasn't able to just delete all the tables and whatnot. So finally, I figured out how to do that and and it was from help from people on the YouTube comments of the Line Street I needed yesterday and it's a simple as using Docker volume LS to list out all of the volumes that you have and then Docker volume RM and then providing the the name of the volume you want to remove and that deletes all the data. And you can also do ducker volume prune and that will remove them all. So, that's what I learned.
Hello there friends, so I've just been thinking about incentives and companies and and the yeah, like what what motivates people to have different opinions and stuff like that. And I want to use myself as an example here because I think it's a there's a lot of nuance with the way that we kind of automatically think that people are have ulterior motives. So, I created epic react to teach people how to learn react. And so my question is did did I create epic react?And then say hey everybody it's React is amazing and like is my ulterior motive in telling people that react as awesome and they should use it so that I can sell courses or did I discover react and I got really excited about it and I and I just think that it's a fantastic way to build it web applications and so as a result of this I create epic reacts as well as all of my other material and stuff. To convince people to use it just because I think that it's a really great framework. And then I finance my my free work by selling.Epic React I can tell you that it's the latter but how do you know. You can't really trust my word for it because my I could have an ulterior motive. And I think this is the sort of thing that's really new on. So just to give you another example, let's say that there's somebody who's really bullish on a particular stock. They maybe it's Apple or something. And so, they they create a YouTube channel that just goes all on on and on and on about how great Apple is. Now our did they create like what order did this happen in did they create the channel and then they say,Wow this is a great way for me to get people to buy the stock. I'm gonna pump the stock up and then I'll my purchase of the stock will be worth a lot. Or is it a kind of more of a combination where they are really bullish about Apple so they buy a lot of stock and they're like man. I just this is such an awesome company. I'm also going to start this YouTube channel to talk about why I think it's such a you know, a great investment or whatever. So anytime you see somebody who seems to have a conflict of interest.It's a very very possible that that conflict of interest is the entire reason that their motivated to behave in the way that they're behaving or speak and say the things that they're saying. It's entirely possible that there's that bias and that's controlling everything. But keep in mind like kind of walk history back a little bit and and think okay, maybe they really have this solid conviction and that's what made it motivated them to go and buy the stock or what motivated them to create this thing and pump it up because they already had that conviction and they don't maybe have an ulterior motive.
Hey there friends. Have you heard of progressive enhancement or progressive web apps? Well, I thought of a real world thing that kind of resembles what this actually means and what it doesn't. So, you know how like there's all these memes of like I got a smart thermostat and now it's broken because my internet went down or something like that and so now I'm like steaming hot like why did I do this and and we have the same sort of thing with my watch and so I have a smartwatch. It's a,Nice one. It's a fossil I guess. And then I also have an aura ring and both of them are useful in their own different ways. But when my watch breaks or if it runs out of battery, which is more often, it doesn't break very like ever. But when it runs out of battery, I'm no longer able to even tell the time. So, it's like totally a break. It's useless as just like a break on my wrist. That is not great. But when my ring runs out of battery,That's also not great but it's still functions as a ring. And so in this context progressive enhancement would be like my ring will always function as a ring but it progressively enhances in that when it has battery it also functions as a way of taking my my pulse and different things like that. Whereas with the watch if it doesn't have power, it doesn't do anything. It's it's not serving its purpose at all unless I suppose if you just like appearing like you have a watch but it's basically.Other than that. And so when we're talking about progressive enhancement or progressive web apps, we're talking about taking advantage of the tools and capabilities of the web and all the modern and cool stuff but not exclusively not at the exclude exclusion of functionality for browsers that don't support those modern features. And so we progressively become a even more capable web app when those features are available. And so in my contacts with the,Watch in the ring that the extra feature that's available is power. And with the watch it doesn't progressively enhance, it just doesn't work at all without that extra feature of power. Whereas with my ring it functions as a ring just fine whether or not it has power and then if it does then improgressively enhances to do a lot of other cool things. But anyway, that's kind of what I think about progressive enhancement progressive web apps. It's kind of an interesting thought. And yeah, shout out to remix particular for taking this.So seriously. I hope that's helpful to you have a wonderful day.
https://kcd.im/trophy https://kentcdodds.com/blog/eliminate-an-entire-category-of-bugs-with-a-few-simple-tools TypeScript is tests. Tests are type script. So type script is just a way to give yourself more confidence. Sure, it helps you in your workflow, it makes you a faster as you're developing because you have autocomplete and stuff like that. And testing does the same thing as well as you refactoring, you know that you didn't break anything you get a much faster feedback when you you're running your tests as you're working on things. And both of these also make the initial code take longer. So it takes more time to think.About the types that you're writing takes more time to actually write the tests. And they can also be an enormous time sink where you spend a ton of time working on a task or a ton of time working on the on the types and then you've later realized that you don't need that code at all so you just throw all that work away. So, I I find that typescript and testing are way more related than they are or similar than they are different. And I think this is a good thing though, the whole goal is to be more confident in the changes that were.Making in the application that were shipping. And the cool thing about TypeScript is that it eliminates an entire category of bugs. I actually have a blog post about that. And it also eliminates an entire category of tests, which you're probably not writing but maybe you should. So one of the things about code coverage is that it doesn't what we really actually need is data coverage or use case coverage because you may have a function called ad that accepts two numbers and add. S them together and you could write a couple of tests for that if you wanted to but you're probably not writing like it's not very normal for people to write a test that says what happens if I pass a string what happens if I pass a boolean but you know, what a you might have a test that says what happens if I don't pass the arguments or something and because there are some defaults. But and that and because there are defaults you're going to want to cover that. But we've very often don't do a whole lot of defensive programming and runtime and type assertions of.You know, what the arguments that were passed? Maybe you do that for some of your functions, but probably not all. And so you can you don't get a much confidence in in that aspect. And you you could but it's just way easier to just use a type to language like TypeScript and then that entire category of bugs in the entire category of tests don't need to be written. So type script is tests.
Good morning or afternoon or whatever it is for you friends, it's morning for me. I wanted to talk about how I type a raise in TypeScript, so there are two ways that I'm aware of that you can type an array and of course I guess there are a couple ways depending on what type of an array you want to make but just like a regular array you can either specify the type and then immediately thereafter with no space a open and closing bracket like the the syntax for an array and the alternative is there is a built-in. Array type which is a generic and you say array and then open bracket no that what are these angle brackets that's what is called an open angle bracket and then the type of that's in the array and then a closing angle bracket and I prefer the latter. I like using the generic array and the reason that I prefer that I I think that I just like just kind of preferred to that from the beginning, but I think the reason that I prefer using the generic array is because I don't,Like reading my type and then getting to the end and be like, oh this is an array of those things so I I see we've got um user and then I see the opening closing bracket and I say oh no, actually it's not a user it's an array of users, whereas if I use the generic I can see oh we've got an array and the things that are in the array are users and so I'm when I'm reading from left to right it just seems to make more sense to me to to read it in that way, it's kind of like in English it. I I like how in Spanish and you have the,If you have like an exclamation you're going to have that upset upside down exclamation point I don't know what that's called but you have that upside down exclamation point at the beginning of the sentence so you know ahead of time that the thing you're about to read is an exclamation rather than getting to the end of the sentence and being oh yeah, I'm supposed to be like excited about in saying this or something like that when I'm reading a book my kid or something and so I kind of see that in the same way and that's why I prefer using the generic over the the special syntax for specifying arrays, it is a little bit more type. Of being or more characters but I actually don't care too much about that and then that comes with the benefit of switching from a regular array to a read-only array, you know being a bit easier and stuff like that so anyway. I just thought that would be something I'd share today. I hope you're having a wonderful day and I'll chat with you soon.
https://twitter.com/kentcdodds/status/1394420201542668289?s=20 So the other day I tweeted about how I really want people to stop minifying and bundling what they send to NPM. And just to clarify I it's fine if you want to minify and bundle as one of the things you distribute as part of your package, but it shouldn't be the only thing and there are a couple of reasons and what I do for my packages is I actually do have a UMD module that is bundled and I have a minified version of that as well. So we have two of those and then I've got an ESM.R version which is like fake ESM right now eventually I'll get around to making a native VSM supported version. And then a common JS and those are the the four formats that I shipped to NPM. So the reason that I really really don't want people to exclusively ship minified code is even with source maps can it can be really difficult to debug and especially when we're talking about libraries that I'm interacting with well even even transitive dependencies. I like to be able to.Stick a console log in there or to step through with a debugger and it's just really difficult to do that if you've minified your code and in particular what motivated me to tweet this in the first place was I was working with a library that minified everything and it ended up minifying its implementation of an abort signal and so the constructor name was incorrect and node fetch actually checks the constructor name to know if what you've passed is an abort signal which we could argue about whether that's necessary or not, but the fact is that it does and becauseThey were minifying it totally is unusable which is a less super annoying. So that's notification then on the bundling side of things this can get to be a real problem like if for example your bundling a particular library and I'm already using that library in my project MPM can't dedupe that and do means it says, oh you're using this library in this other dependency uses that library too. So we'll just have them both use the same files and therefore we don't have to send.That code to the browser twice so we don't have to require that code and evaluate it in person all that stuff. And so there are arguments that people make about bundling as like performance improvement so like you could do that with some tools and and that could be useful but it could also be a big problem because then I can't like change the versions of the things that I'm using and I don't have any control over that. So there are a lot of issues there in general. So, please don't bundle don't minify it's better this way. Let meDo that.
Hey friends, so I'm working on this little remix app and just something about remix that I just this so cool the fact that your server and client side code run is written in the same file if in case you didn't know that that's that's what you do and it's really cool for validation so you can start by validating just a hundred percent on the server and remix makes it quite nice to be able to do that and that's where your validation should absolutely. 100% go by default that's like if you're gonna do it anywhere do it right there, but having client side validation can be nice for you know, showing error messages and stuff and so because the client side and silver side code is written in the same file, you don't want to like duplicate that that logic and so you just extract it to a function and then in the server you call that function and the client you call that function and when remix shakes out all of the stuff that function will appear in both places, but you don't have to write it twice and so. I'm just writing out a form right now and I had a a maximum length for a particular field and so I can just put that variable outside of everything and make sure that I only have one specific place where I say what the max length of this is gonna be and then I just use it in the client and in the server all in that same one file. I don't need to like put in a different module and import it or anything it's all just right there and I just think that's awesome that I I'd share that with you remix is just my friends it is something else. IFeel super productive working with this and yeah I the cool thing is that it's I feel like it's both pretty quick to get at for it to become familiar so it doesn't take the long for it to become easy relative to other stuff that I've worked with but it also seems so simple and so therefore I can build simple applications with it and and and and I I mean, I haven't written an application in a million lines of code with remix and,You think but I feel like this would scale well to that based on the experience I have in writing and working on enormous applications, so yeah anyway remakes it's it's awesome and I know that I gush over it but there's a reason it's not it's certainly not because Ryan and Michael are paying me in fact I paid them to be able to use it so there's there's no conflict of interest there, they're my friends, so they're there's a full disclosure but this thing is out of this world, so if you haven't taken a lucky remix yet and give a good look at it. See ya.
https://kentcdodds.com/blog/make-your-test-fail Hello there friends. I'm just driving now. I was thinking about a blog post that I wrote a while ago. I think it was called break your tests or something like that, but the idea is that it's just really easy to write a test that passes and so you feel really good about it this this especially happens if you're testing after you've already implemented something if you're doing TDD this is maybe less of a problem, but it's really easy to write a test that's green and we're happy with it and,So we commit it and we move on and then we later find out that that test wasn't running to completion or it was the it wasn't testing what we thought it was testing wasn't making the right assertions or something and so it wasn't actually doing what we thought it was and so then the thing that we were intending to test ends up breaking in that test doesn't doesn't save us from that and so what I suggest that you do is you take the time to actually try and make the thing that you're testing break, so you simulate a failure this could be. I'm pretty much like any any step of the process of what it is that you're testing maybe you're making a request to get some data and then you're displaying that data in your asserting that the data is displayed properly and so you could just comment out the code that updates the state or something like that and so it's normally very easy and it's a manual check. I don't think that there would be a whole lot of use in like at this point you're testing the tests and I don't see a whole lot of benefit and like how far do you go, do you test the test the test the test?It's just sorry cracking myself up um yeah so like at some point you have to say okay, we're good with just doing a manual verification of this and so that's that's what this is is just a manual verification that yes this is indeed testing what I think it is and I verified that by commenting out the implementation or changing the implementation and in a certain way to make sure that the test will catch me if I mistakenly change the implementation in this way, so yeah, as you're writing your test for your software, I suggest that you break the test and I will. Add a link to the blog post where I dive into this little in a little bit more detail at the top of the notes for this episode so you can go take a look at that. I hope you have a wonderful day and we will chat with you later bye.
Friends I'm out and about today so we might hear some like music in the background and stuff but yeah today I wanted to talk about cypress driven development. I was working on something that I'm working on for the new website where you can submit a recording of a question and then I'll be able to answer it's gonna be really cool but it's all like in browser recording stuff and lots of what I was testing was like required me to have to record something and then to continue on through the the work. Or the flow and that was super annoying to have to you know, make a change and then go through that whole flow again and so I was like, well, this is the perfect situation for cypress different driven development so I made like a I don't know ten lines cypress function or or test that went through that I did have to do a couple fancy things to make it so that cypress would accept a fake wave file as input which I made a maniacal laugh and I found online but uh, yeah, once I had that I'll set up it was really. Cool every time I made a change to anything I would just have cypress rerun it would rerun automatically and and then I could look at the terminal output or the console output and get a good idea of what what was going on so yeah I was really it was like nail on the head for cypress driven development. I don't think that it's always necessary but especially when you're working on workflows and stuff and like this is the sort of thing that hot module replacement like yeah, maybe that work okay, but just is not going to do it for you.For this sort of thing like I never really trusted how much of a replacement and so the and this is the one situation where people say, oh yeah how much replacements really nice if you're like what you're working on is pretty far into some workflow or something that you don't want to have to do over and over again, well, sometimes you do need to refresh for one reason or another and having cypress just get me back into that state and like a half a second yeah that's awesome and it's like a real actual experience so if you've not tried cypress driven development. I suggest that you give it.A shot because it's really helped me be really productive and at the end of it. I'm I may actually be able to use this as a test as an actual test to keep me confident so there's that I hope that's interesting and helpful and useful to you and hope you have a spectacular day you take care and all talk to you later.
Hello friends So today a friend of mine on the KCD Discord is named Rupert. I'm not sure. I'm pretty sure that's how you say their name. But I created their very first poll request for open source. I wasn't aware it's the first poll request but they did a great job. And it was for the KCD Discord bond. And so the discord has a lot of cool things you can do with it and one of them is they're a bunch of commands that you can give. One of those commands is the thanks command where you can give somebody extra kudos to say thank you and we'll record. The that in a thanks channel so you can look at and see all the people who've received gratitude and who've given gratitude and then it will log that in a github gist. That's our storage mechanism for this bot. And and actually, I think this is the only thing that requires storage that we have but um, it's ends up being just this giant JSON object. And so we've had this for a while Marco built it initially and it was cool because you could say thanks ranked top and it would give you the top.10 people who'd received the most thanks. But I wanted to also have a rank for the people who give the most gratitude as well because I think it's a nice to to have that. So he Rupert made the a change to also allow you to say thanks gratitude ranked top and that would give you the the top 10 most grateful people in the server. And it was just kind of a way to recognize people who are making our community special and and grateful thankful. And,Yeah, so I just kind of wanted to talk about that just a little bit and say, hey, you know gratitude is important and it's helpful and in fostering a community that I want to be a part of and hopefully you do as well. And by giving a just the little bit more recognition for people who are grateful, but also the people who are being thanked, so the people who are doing helpful things. I think goes a long way to making people more encouraged to continue to do helpful and,And good things and and also to be more grateful. So and gratitude has been scientifically proven to improve people's overall happiness. So if you're a grateful person, you're happier. So go be grateful today, and if you're a member of the KCD discord, then go say thanks to somebody using the Thanks command. And if you're not then joined because it's a cool place to hang out. All right. I hope you have an awesome day and we'll talk to you later.
So let's say that you want to convince your coworkers to try a new tech or something like a new library or whatever and you think it's a really good idea but people aren't convinced. So what typically happens is you want to prepare a couple of ideas and stuff and bring it to a meeting and say, okay, here's here's what I think and why I think this is a good idea. And then people will present their reasons why they they don't think it's a good idea. And people may come to the meeting kind of predisposed to disagree and and want to just say,No this is just extra work that you're making me do and and so as soon as somebody gives a reasonable good argument against you against your idea for everybody else that just is like the thing that they can latch on to and if you're not prepared to deal with that then then you just lose everything. So this is what I do and what I've done to convince members of my team that my idea is a good one. And that is first you have to like that obviously you have to really believe that it is a good idea and you wouldn't want to present something that's not necessarily a good idea. But then,What I have done is I will reach out to everybody who's going to be coming into the meeting all the decision makers, but also just the people who are going to show up so even people that may not be making the decision they just might voice a concern of some kind. And I will just ask them what are their preconceived issues that they have with this idea? And I'm just talk a little bit about it not. We're not here to have an argument or anything about the merits of the idea. We're just here to gather their hang-ups with it. And do that with everybody who's coming to the meeting so that you can prepare and bring up their arguments before they have a chance to bring them up and and you bring it up in such a way that you can immediately address it and say now some of you were worried about this, let me explain why that's not a problem. Or you may not even need to bring that up. You can just solve that problem before they before mentioning the problem in the first place. As part of your presentation, this will go miles to help you convince people that your idea is a good one and help alleviate concerns and they're concerned. The real and you need to address them But if you want to have success and convincing people you want to avoid the mob mentality where one person shares something that's like now this is not going to work for this reason and everybody just latches on and they won't listen to your explanation. And maybe you'll get caught off guard too in that situation. And so by asking ahead of time you are made aware of things that you may not have considered and you make sure you address those and it's also possible that you can cancel a meeting because you realize that oh actually this isn't a good idea because of these concerns. So anyway, this is something that's helped me in the past. I hope it helps you and I hope you.
https://staltz.com/your-ide-as-a-presentation-tool.html Hello friends you may have noticed that sometimes I use my editor as my slides in lots of the talks that I've given over the last few years and that was originally inspired by André Staultz who has the a blog post on his website called your IDE as a presentation tool where he kind of explains why he has done that and it's a good blog post you can take a look at that and even gives tips on how to do this effectively and stuff. But I would just thought I'd mention why I like doing this. I actually am working on some slides right now for.A talk that I'm giving and I I've gone through so many different ways of making slides like I started with you know, Google Drive and or PowerPoint and and went on to I actually used Prezi for a while which was fun and and slides.com is probably where most of my slides are and I really like that one quite a bit. I've made things simple. I used MDX deck tried to code my slides. And finally, I've kind of landed at using my editor for my,Slides because I think that just makes the most sense or it's just the the easiest for the types of presentations that I make which involve me moving my cursor around the screen highlighting text and maybe even adding text especially if I have some code samples or stuff or I want to like demo something. It's all just right there in my editor I can type and add things and it just makes things a lot a lot easier and I would be lying if I didn't add or if I didn't say that there's a piece of me that kind of likes this approach because it's just,Way easier to make these kinds of slides. And I sometimes see people who make just the most beautiful slides slide decks, and and everything is custom often like related to the conference specifically and and I am really impressed by that stuff and I think it's awesome and if that's something that you want to get into that's super great and I'm yeah, I'm impressed by that. That making things look good is a real struggle point for me and thinking about like animations and stuff like that too.When I did MDX stack I struggled a lot with making things responsive so that it would look good regardless of the size of my screen and stuff and it was just such a pain. So using my editor just gives me a lot of benefits and then I don't have to worry about all the extra things that I struggle with. I use markdown for pretty much every slide and then sometimes I'll have a gif in there as technically a slide. And you can take a look at this blog post that I'll add a link to to get a better idea of how I do this. Anyway, I just thought I'd share that.Maybe give it a try. See ya.
https://epicreact.dev/the-latest-ref-pattern-in-react Hey your friends. So I get this question of fair amount and so I thought I'd try to answer it and podcast form and the question is why don't why is it not a good idea to set a ref during your render function? So there are exceptions to this and understanding the reasoning will help you understand what those exceptions are. But basically, if you read my blog post on the Epic React dot dev slash articles, there's a blog post about the latest ref pattern and in that I put a use layout effect and,There with ref dot current equals some callback or whatever And a lot of people ask me why do you need to put that in a use effect? Why can't you just put that? You know you're calling it every render anyway so you may as well just put it directly in the render function. So the reason that you don't want to do this is it actually is mostly just for future proofing. So right now that will technically work and it and it there shouldn't be any problem with it, but when eventually if the reacting does finally release concurrent mode as an official feature of React,Then you could wind up in a problem and that problem would be very difficult to reproduce and very difficult to debug. So in general, this is why the react team is just been so adamant about your render methods being item potent, which basically means that it can be called as many times as it reacts once to and the same thing will occur regardless of how many times this function is called. That's like an oversimplification of what that means but anyway, so imagine a scenario with a concurrent mode where reacted.The rendering your reactor and then a high priority event happens as it's going through rendering and so it says okay never mind, let's stop rendering will deal with this high priority event and then we'll come back and we'll re-render stuff and so if you set it during the render function, you may actually be setting it to a value that is never actually used and so potentially if you end up using that you're using a value that was created for a render that was never actually committed to the DOM. It's hard to describe the bugs that you.Could have there but hopefully you understand why that could be a problem. And and so it because there's no real issue with putting something inside of a user factor used layout effect and that's really the only time where you can run code and be certain that the render was actually committed to the DOM then you may as well just put it there and make sure that you keep your render functions side effect free. So, hopefully that kind of made sense is interesting and useful. I hope you have a fabulous day andTake care.
Hey friends I had an interesting thought this morning. So a lot of people when they start using a new technology like when next was released or when you know a new version of Reactor or or any React library or whatever they often will say, okay, how do you I use this with an existing technology that I already enjoy like, so how do I use next with glamorous? That was an early thing. I remember or how do I use? Next with Jest or you know, whatever whatever it is. I would encourage you to when you're using anNew technology to avoid bringing in your previous and older or like the the previous technologies that you were using in conjunction with this new thing too early. So what I mean by that is often we get really that we're using an existing thing and say we're using create react app. And we really like emotion for our styling. And so then we decide okay, I'm gonna switch over to a remix from Create. React app and I'm gonna say okay now I really like emotion for my styling so I'm gonna come in to. That and try and figure out how to use emotion with Remix And I would discourage you from doing something like that right from the get-go. And the reason is that part of why we love our tools so much is because they solve problems and and that's that's great and they solve them in a way that we really enjoy. But if you bring all of your old tools to the new technology or to the new framework or to the new other thing, you might find that things don't work together quite right and that could give you a bad sense of what is possible or whatever like a it might. Put a bad taste in your mouth for that new technology When in actuality it turns out that you don't need or let me rephrase that you don't have the same problems that made you fall in love with this original tool. So remix is a great example of this because it just eliminates so many problems and so if you try to bring in solutions to problems that don't exist then yeah, you're probably going to have a hard time. You're going to be like, well, what is what is remakes all about? I'm not actually this wasn't triggered by anything specific. I haven't seen anybody say wow. I don't like remakes because it's hard to use this tool. It was just a thought that I had this morning.And yeah probably would be a bit of a pain to to use some tools with remix but just make sure that those tools are still awesome when you have a framework that may eliminate that problem altogether. So when you're learning something new, this is why I do my super simple start blog posts just to give you an idea of what this thing has to offer all by itself and in particular with remix actually just regular CSS files, you'll be blown away how good it works with just that. Anyway, I hope that's interesting and applies to more than just Remix have a wonderful week.And a wonderful day. Whatever you listen to this have a wonderful one.
https://www.scriptkit.com/ https://kentcdodds.com/blog/automation Hey friends So you know how sometimes you do things so many times that you're like you know what I'm just gonna write a script for this and we'll run it and whatever and so I don't have to do this over and over again. And like some of those things can be pretty extensive, like there's a lot of stuff that you end up doing like you gotta open up this webpage and then you gotta click on that and then you gotta go do this, whatever. And some of those things can be like really simple. So I just need to open this file add a line to this and save it and then close my editor or whatever. And you can speed all of those things up using like little CLI to.Pull that you make or something and the the value of this isn't necessarily in the amount of time that it saves you but in the amount of context switching it saves you from. So so you don't have to pull up your whole editor, you don't need to pull up this tab or whatever it is. I actually have a blog post about like why saving time isn't the only reason to automate things which is kind of a good blog post. You can go check it out. But what I wanted to tell you about today was there's a much better way to automate stuff. Especially if you're a Mac user Windows support for this is coming.Eventually but what I wanted to tell you about is this tool called script kit by John Linquist. So if you haven't heard of script kit, it's sort of like a spotlight or Alfred or or what what's the thing on Windows that you like you just hit the Windows key and then you can type something. But yeah, it's just this little key combination that you can execute anywhere and then you type something and you can execute some little script that you have. So script kit it's it's really really cool and once you start creating these little auto.Mations and there are a lot of cool things you can do. And it has some really awesome APIs for accepting arguments and and for prompting you for additional information, you can drag and drop files all sorts of really cool things that I just strongly urge you to take a look at and see how it can improve your life. So one thing that I do is I have a script that will automatically update dependencies for all of the epic reacts workshops, and so yeah. I just run this script. It opens up. What is it seven?To terminals for the seven repos that epic or maybe eight repost synaptic react has and and it updates all of the dependencies and and then pushes that up automatically for me. And so that I can keep things fresh and quick and it doesn't take any time. I've got another one that allows me to quickly open up any project that I have in VS Code and it's just it's much quicker than opening up a terminal and doing it like executing a script. So take a look at script kit, it's super cool. Have a nice.Day.
https://youtube.com/c/RyanFlorence Hey friends So I was watching a live stream from Ryan Florence last night while I was putting my kids to bed They were falling asleep and I was in the room to make sure that they didn't go all whacko and stuff while they're trying to fall asleep. And so I was just watching Ryan codeps some stuff. You should check it out. Actually Ryan has gotten some really good live streams recently, especially if you're interested in remix and stuff. And and actually sometimes I'll just watch it during the day. I'll just have it on in a different tab while I'm working and if I hear something that sounds interesting I can go over there. So, it's kind of fun and interesting.And and yeah it's kind of fun to be on this side of the live streaming stuff at home but anyway one thing that I noticed that Ryan doesn't and I've seen him do this any time that I've seen him code not just in this livestream. So he's been doing this for a while as far as I know. But he has this document open in his editor that's just like marked down format stuff. That outlines exactly what he plans on doing for that coding session, or at least he kind of keeps notes of the things that he's still needs to do. That's not exactly pseudo code, but like, you know, create a user then save that users.Session in the database and then, you know, whatever else. And it I I I like this approach for me. I typically just have in my mind this idea of what I want to do and then I just go scramble around and and do the activities until those things are all finished but it's not as directed and I feel like I could definitely improve in this way and and get a little bit better at making sure that I'm accomplishing some specific tasks and and it also at the end of the day, you feel like you got a lot more done. I do have a notepad that I,Where I write down all the things that I'm gonna do for the day but normally that includes stuff outside of coding and then I've got like work on this work on the website or whatever. And it would be cool to get a little more granular especially when you're working on new features and and stuff like that. So I just thought that would be an interesting tip to share so next time you start working on a particular feature go ahead and just open up a text file and write out kind of outline the different tasks that you need to get accomplished and every couple minutes or so review that. And see what you've finished and and what you need to work on next kind of help direct your your thought process and and implementation so that you get things done. And of course, you can always do it like test-driven development style if you want to but some of these things would be a little hard to test drive. So in those situations having a list can be really helpful. Anyway, I'm gonna give this a shot some time and hope you do too and I hope it's helpful to you. Have a good day.
https://twitter.com/kentcdodds/status/1388561641382420480?s=20 Hey friends So a few days ago I tweeted something about like don't solve problems you should eliminate to problems before you try to solve the problem. Something like that. And I've been thinking about this quite a bit recently and probably going to write a blog post maybe even make a talk and for this concept. But I just wanted to share with you all while I'm thinking about it and and there there are lots of examples of where eliminating a problem was much better than trying to find a solution to the problem. And you can find these as.Sorts of examples in real life as well as in programming. So like an example in real life and actually I was watching a video about this this is what kind of made me start thinking about this was Tesla how they eliminated a ton of problems with gas-powered vehicles by making an electric vehicle. And so we no longer have I mean and we kind of create new categories of problems that we need to solve but by taking a completely different approach you can eliminate the existing problems. And so, hopefully the new category of problems that you create.Are not as bad or easier to solve than the problems that you're eliminating. And they've got actually lots of really cool innovations that they've done that have eliminated problems like for example, they have this gigapress thing that I'm kind of cast a huge part of the the car all at once and so they don't need to worry about like the dozens of robots and welding and different stuff like that. They just eliminated all those problems all together, which I think is really pretty cool. And in a program,Ming situation, we've got remix has eliminated a lot of problems by just having nested routes and they eliminate problems with caching and and a bunch of the the like all of the abstractions that we build like react query or formic or different things like that, those problems are eliminated by embracing the fundamental aspects of the web and just the way that they solve these problems. I'll have more time to delve into some of these examples and in a blog post might?Talk but remix is another great example of eliminating problems and again you do create new problems but hopefully the problems you create are not as bad or easier to solve. And then finally react hooks eliminated a bunch of problems with classes. We have some new problems but they are definitely classes had so many more problems than hooks, so I'm really glad of this change too. So anyway, I'm trying to think today of like some things that you use or some problems you have and see if you can eliminate those and yeah good luck with that. See you.
https://kentcdodds.com/blog/solidifying-what-you-learn Hello friends So recently somebody asked on the KCD discord whether they should bother writing a blog post because the topic had already been covered a thousand times by other people who may have more experience in whatever. And I shared with them a blog post that I wrote quite a while back called solidifying your understanding or something like that. And in it I mentioned a an interesting phenomena that I'm sure you've noticed sometimes you will be walking down the street and you'll see there's a McDonald's I really like a burger or whatever but then right.Next to it, you'll see a burger king. And then like we wonder sometimes like why would Burger King put a building here if there's a McDonald's right next door like they already solved the I need a burger problem why why would they bother doing that? And the reason is because people's taste are different and people enjoy the the burgers, you know, or whatever quizzing you want to use as an analogy here. They enjoy that differently and they,And they have a different take on that But even if you don't have a different take even if it's exactly the same there's still value in that. There's a street intersection down in Texas somewhere that has three Starbucks on it. So they're missing one Starbucks to get all four corners three Starbucks, I think one's in a Barnes & Noble and others in some sort of internet cafe or something and then there's an actual Starbucks but you you can get Starbucks on any three of those corners and and and it works and it's fine and people enjoy it and they you know, clearly there'sThere's business for that and in the same way there the internet is so vast and your reach is different from my reach is different from his research is different from her reach, whatever we're all over in just the way that we can reach people, especially if you know a language other than English if that's the case then you can reach people. I simply can't. So definitely right that blog post to create that video make that content because the other side of this is that the,Content creation isn't just for the people consuming the content In fact it's often especially the beginning it's more for the person who is creating the content. You learn a great deal by creating content at educational content of some kind explaining things. You can teach yourself in the future. You can go reference it later, but also the process of creating that content is going to make you understand it better. So, yes, I strongly advise that even though that everybody's already written about this or whatever go ahead and write about it yourself. You'll learn more and you'll reach more people thanAre already being reached. Hope that's helpful. Have a good day.
https://www.typingtest.com/test.html?minutes=1&textfile=mediumText.txt&mode=sent&result_url=/result.html&bt=0 Hello friends. So this morning in my discord we had a little bit of a conversation about touch typing. One of my friends there asked if they should get into Vim and they were thinking that Vim you can move a little faster and well I think that's that can be true. I think there's a little bit of an illusion to moving quickly just because you're using a special text editor or editor or a VIM like key bindings thing. I think you can get just as fast without them. And I've been on both sides, but yeah, andNow I'm not using them keen bitings But anyway I think, we kind of came around to touch typing was the thing that was selling them down. They could improve their speed if they just were able to type a little faster. And so I thought yeah, I just got me thinking this morning about how valuable it can be to be able to type very quickly. I think most of us have been in a situation where the interface to the computer wasn't fast enough for our brain where we knew exactly what we wanted and it was just a matter of getting what we wanted into our hands andInto the keyboard and into the computer. And so in particular, sometimes I say hey if you aren't sure about which direction to go with some API or something then focus on building both versions and choose which one you dislike the least is kind of my approach to things and so what it's it's not without cost to do that like it does cost to build it both ways, but if you like have it in your mind of what those ways are going to look like and and it's not like a huge. Investment of mental energy to do it then the investment just comes down to how quickly can you type and you can reduce that investment by learning to type quicker. And so if you are not at right now I took a typing test and in a kind of real world sort of test. I'm at around 88 words per minute and so I'm a pretty fast typer or typist however you want to say that. If you're not at around that pace then let me just tell you that the human body is capable of really amazing things our brains are are capable of amazing things and you can probably work your way up. To to much quicker than you are And I would encourage you to put some intentional practice into that if you want to improve your typing speed. Now, there's a lot more to coding than just the typing speed. So don't worry about that. I spend way more time thinking than I do typing but I know situations where typing is the bottleneck it's really frustrating if you're not very fast at it. So I'd encourage you to give it some intentional practice. Anyway, I hope that's helpful and interesting I will add a link to a the typing test that I took so you can take it yourself.Have a good day.
Live stream link: https://youtu.be/4dOAFJUOi-s Hey friends. So today is an important day for a friend of mine. Our friends of mine Michael Jackson and Ryan Florence are releasing the beta 1.0 release of remix. And if you've been watching my Twitter or just kind of me in general, I've been really excited about remix. I've been reading writing can't seedance.com to remix and it's just been a total joy. I am super excited about the potential that remakes has and really excited about the approach that they're taking and.From a progressive web app standpoint whatever So if you're listening to this on the same day that I'm recording it then don't miss their live stream that's happening later today because it's going to be great. I'm certain of it like they haven't given me a preview or anything but I'm sure it's going to be great. And I really encourage you to give some serious thought to remix as an option for the apps that you build in the future because it's phenomenal. The their approach to focusing on the foundations of the web and the and the features like we spend so much time. Building JavaScript libraries and and abstractions for what is already built into the web platform just because we don't want to use it the way that the web platform has it for whatever reason but remix kind of brings it all back to those fundamentals and what that means is that the knowledge that you gain as you work with Remix is very transferable. It's all based on the the platform that we've had for decades and it's much more powerful than just our own little abstractions that that we try to build.So anyway, it is really incredible. I'm really excited about remix and I am yeah don't miss their live stream about it today. I will put a link in the transcript here but you can just go on YouTube and search for remix JS and you'll find their channel and you can watch the live stream today. Yeah. I think that's all that. I I don't want to dive too deep into things because I don't have enough time in this three-minute podcast, but yeah, I have never felt. So excited about a framework before or like a meta framework like remix. It is phenomenal. So anyway, I'll stop using all these fluffy words to describe it. And you'll see more about remix coming from me, absolutely. So look forward to that. Hope you have a great day and I'll see you around.
Hey friends so I wanted to talk a little bit about open source. I have been doing open source for almost as long as I've been doing software development. And it has been just an enormous benefit to me. I I can't tell you how how much I've learned and how much of what I know I learned through open source and so I strongly advise people to get into open source for various reasons. In particular, like it makes you a better software developer, you write higher quality software, you can reuse the software that you create.In a other projects and so yeah it's a lot of fun to get involved but a lot of people ask me how well there's there's two sides of this how do I get started and then how do I make sure I avoid burnout as that is the thing that happens for open source developers. It's a pretty thankless job in general like that, you don't get financially compensated most of the time and stuff. So first of all how to get involved. I have a blog post that goes into more depth on this. It's called what open search project should I contribute to or something like that. And the assertion is that you contribute that.Is to something that you use regularly or that you have experience with. And so when people ask me, hey, do you have anything that I could work on which does happen occasionally. I always have a hard time answering that because I don't know what you use. So it'd be better if you find something that you're using and you can work on improving that in some way. So think about the tools or or the libraries that you use and find ways to contribute directly to those to make those things better for yourself and for other users. And then,On the other side of things if you get too into open source and you kind of lose track of things and and are starting to burn out. My strategy for that is I never work on anything that's an open source that I don't need or don't want to work on just for fun. And so when somebody opens an issue on my project or something if if it's a feature enhancement or something that they want, but I don't need it then sometimes I'll just ignore it. Normally it's nice to to let them know that they can make a pull request or whatever andEnable them to do that But other times I just don't have the time and so I just kind of ignore it and and you know, they can always fork it. So it's never like a dead end for them or anything. So yeah, that's kind of how I avoid burnouts. If I don't particularly want to do it for the fun of it, or I don't need to do it for my own stuff then I just don't bother and I've been doing open source for I don't know like six years or so or seven years and it's worked out pretty well for me. So yeah, I encourage you to get into open source. Have a good time with it. Bye.
Hey friends So I am working on a rewrite of my website can see downs.com and one thing that I'm adding is user accounts so you can set up an account and I'm not going to tell you why you might want to do that. I have a little bit of a surprise. But the reason that I mentioned this is because I'm using Firebase authentication and I started out with the username and password regular old username password sort of thing that you're used to. And it worked pretty well. I had a password reset. I had forgot my password. I had changed password and updated email all that stuff was all implemented butIn as I was working on all of this I started to I think personally I actually really like the magic link for stuff because for various reasons it's it's incredibly more secure. So like if I were to have a data breach which of course, it wouldn't be me it would be Firebase I would have the data breach. So, I'm not really worried about that. But if that were to happen or rather for services that I use I prefer and that they use magical links because if they were to have a data breach all that's lost is my email address, which is,Everywhere There's nothing secret or private about my email address. They wouldn't be able to get my password. And I do use a password manager, but I wouldn't need most lots of my family doesn't use password managers. They have either some sort of algorithm. They've come up with for generating passwords, which I used to do actually or they have they just reuse passwords or whatever. And so data breaches don't reveal any passwords of any kind. And so that's it's way more secure in that way. Because there's just no data to lose. But,The other nice thing about this is or or the like the biggest concern that people have with this as well. I do use a password manager and if you don't have a password then I can't put you in my password manager. And no, that is false. You can definitely create a an email only entry in your password manager. And the reason that you'd want to do this is if you have multiple email addresses, or you use email aliases or something. Sometimes you can forget which email you use for a given service. So you just add an entry to that email or password.With the email that you use and just don't have a password. And then it makes the implementation way easier as well. So there's no need to worry about password reset or or securing the password or changing the password or any of that. So like forgot my password all that stuff just goes away. So you can get rid of a ton of complexity just by eliminating the password. So I am all in on magic links. I think that they're great and if you don't log people out automatically after a couple days then or you keep them logged in for a month or so. Then,There's no problem with the user experience either. Have a good day.
Hey friends So some of you may be familiar with my super simple start series of blog posts. I've got like six or seven of those and basically the idea is let's strip down everything else outside of the thing that we're trying to focus on and just bring in the abstractions or tools that are 100% necessary for whatever whatever it is we're learning and that means if we're talking about CSS variables or custom properties, that means we're not bringing in Webpack or any of that nonsense, it's all just index HTML and then style sheets and stuff. And we're talking about react same story. We get rid of the build tools just get rid of all of that stuff and see how minimal we can make something work just kind of the hello world of this. We we don't care about whether this solution scales or anything and the idea is if we can separate the specific thing that we're trying to learn from all the extra things you need around it to make something practical you'll understand a lot more what the the role of that thing that you're trying to learn is. And so,It just has helped me enormously where with regard to working with node modules like native ES modules or even the native ES modules in the browser. And so this is something an approach that I take when I'm trying to learn something new or maybe when I'm trying to introduce something new to somebody as I try to just pair it down as much as I possibly can to remove all of the noise and just focus on what we're trying to actually learn and it's been really effective and so I wanted to share that with you as an. Idea if there's something that you're trying to learn and you want to just really get a solid grasp or understanding of a specific technology or whatever then try to make a super simple start to whatever it is that you're trying to learn. And I think that you'll find it's surprisingly easy to do typically or it's a lot easier because you can just ignore a ton of other things that we always have to think about when we're building real apps. And then it also helps a great deal and actually being useful. So anyway, I hopeThat's helpful and I hope you have a wonderful day.
Hey folks, so today I want to talk about trust the process which I just barely looked up and apparently it's a slogan used by fans of the NBA's Philadelphia 76ers and now it's just everybody uses this and I use this and one of the things I think that I mentioned on three minutes with Kent months ago, when I started this new year one of my or my kind of goal or theme for the year was planning and the way that I executed that theme was I have a notebook and a pen that I keep in my pocket. And at the beginning of the day I'll just look at my calendar and the things that I'm I need to do or maybe at the end of the day for the day the next day and I write down a list of all the things I want to get accomplished and so far this year. I've done a really good job of keeping up with that process it's worked out pretty well. I had slipped up a couple times for like when we do spring break and stuff with the kids, but for the most part I've been doing this really well and it's worked out just phenomenally so I it's a pretty small thing. But it's it makes me feel a lot more productive especially during on those days where you don't really feel like you get a lot done and you can look at your list at the end of day and say yeah sweet I did get a lot done or maybe like wow that one item on this list just took the whole day. I didn't expect to expect it to to take all that time, but at least you can kind of reevaluate and think about the things that you got done and you can prioritize things and make sure that you don't spend so much time on the little things on your list that you miss the more important things and so you. Can see it all in front of you and prioritize so this is worked out really well and there are times where I think man I'm just not getting as much done that I want to but then I just trust in the process and make sure that a I'm being as productive as I can and I can't really ask much more of myself so anyway for today. I just want to encourage you to trust in whatever process you come up with and if you don't have a process, you don't have a goal or something specific that you're trying to achieve then I recommend that you get one and actually it's Scott Hanselman was on.Chats with Kent a while ago and he and I had a great conversation about being intentional about what you want and about how you spend your time and I just listened to it again today. I'd suggest that if you haven't listened to it already go listen to it and if you have give it another listen because it Scott is just really inspiring has a lot of really good ideas and so yeah, if you haven't listened to that go go to https://kcd.im/podcast and give that a listen. I hope that's interesting and helpful to you have a wonderful day.
Hey folks So I have had a couple of in situations when I was writing some tests where I had some code that would give me some sort of warning maybe it's using the invariant module or I'm just doing a console.air or consultant more or something like that. Or maybe I'm rendering a React component that will throw an error or something like that and I want to write a test to make sure that that error is thrown or whatever. So in in these sorts of scenarios, you're going to get console.errors getting logged. And so, I just wanted to talk about how I do that. So what I do,Is I am I do just that spy on console error and do that in a before each and then inside the test itself. I will define what I want it to be mocked as and I don't want to have my tests muddied up by all the console output from my source. So whether that's console.org, or error or log or anything, I want my test to be totally free of all of those things. And so if I'm expecting to have some logs of some kind as I'm running my tests, I'm going to need to mock all of those things. So that I don't have aBunch of noise in my test output And so typically console.ir is going to be mocked and I'll say mock implementation empty arrow function, so it doesn't actually log anything. But sometimes this can be a problem because sometimes let's say that you are expecting to get an error but you're not going to be getting the like the error that you get when you first write it actually you get a different error for a different reason later and if you don't assert on the error that you actually got then you'll be in a bit of a bind and so you when you mock the implementation like that, you want to make. Sure that you are asserting that yes, this was called and we know what it was called with. So you want to insert what it's called with?The other side of this is let's say that you want to make sure that an error is not called because you're handling a situation where maybe react with typically error like for example when you unmounted component and a request finishes you want to make sure that there's no error about setting state on an unmounted component, for example. And so in that case, what I did just today was I set my error at or I I did spy on my error, but I did not want it to want to mock the implementation. I want to keep the original implementation.And then, I perform all my actions, whatever NI assert that the console error was not called. In this case, you do not want to unlock the implementation because if you do have an error you want to be able to see what that error was. So anyway, I thought that might be interesting. And in yeah, if you ever run into situations where you have a bunch of errors or logs or anything, just make sure you clean those up. So, they're not distracting from the output of the test. Hope that's interesting. Have a wonderful day.
Your friends it's a beautiful day it's Monday and I wanted to share just something that I discovered while I was working on something just kind of an interesting workflow that I've come to start to use and that is if you are trying to use something and you don't know what type it requires rather than and assuming that it's written in touch script or at least has type definitions so like say you're passing a function to an API and some sort of callback, for example, maybe you're on an input in a j in your JSX and you have an on change in your not sure what type. The event should be or that first argument or you don't even know whether it accepts arguments or anything so the way that I do this is rather than opening up the docks and digging around and trying to find how this is to find out what I'm expected to do here you put in a function that you're pretty confident is going to break the types in some way and so for our input on change example, you can just put an inline function in there that takes a single argument that you type as null or something and then you're going to get an error and the error is going to give you. That the last line on the error is going to say that type such and such is not assignable to type null so in our example. I literally have this pulled up that's where this example came from but in our example it's type change event. HTML input event is not assignable to type null, so now you know that it's a type change event and if you're not sure where that change event is coming from then you can F12 into the unchange prop and it will take you right to where that is and here I see it's a type change event handler is what that type is and if we F12 into that we just keep on F1 eventually we're going to. Find that this is typed as an event handler that accepts a change event input type or type as it's input ultimately this ends up just extending this synthetic event and it has one additional property a target interestingly that's an event target of the the given element so what was interesting about that actually is that that means that the target for a change event is equal to the input or to the current target. I'm guessing so that's interesting anyway, so yeah, that's just kind of a general tip if you.You're working with something you're not sure what at least for our function you're passing this function you're not sure what arguments it should take pass it something that's just bogus that you you don't know if it's right or you're pretty confident it's wrong and the error message should give you an idea of what you are actually supposed to do there and you can do the same with the return value as well so like return a symbol or something that you're confident will not be what you're supposed to return and you'll get an error message indicating to you or giving you an idea of what you should return hope that's useful and interesting have a wonderful day.
https://youtu.be/gzq5AFCH5jk Hey, you're folks. So today I listened to a podcast interview. It's about 50 minutes on. And it is on a podcast called Tesla daily. I which is a kind of interesting daily podcast about tests huh? But normally it's it's like a 15 minute long thing, but this one was 50 minutes and it was an interview with this fellow by the name of well, it's not showing the full name here. James Duma and yeah, I,Don't I've never heard of this person before but they are really great at explaining neural nets and so I wanted to share this with you wanted to um, just encourage you to go give it a listen. Some of it was like hmm, I'm not sure I get this but after like thinking about it more and and listening carefully to that James explain it, um, I I feel like I have a much better understanding of neural nets now than I did before and I thought that you all find that to be kind of interesting, so I'm gonna include a link to theIt's on YouTube I I'm guessing this is also gonna be published as part of the the daily podcast that you can subscribe in your podcast reader or can whatever app that you use but I was really interesting kind of explaining how neural nets work especially in the like thinking about it from the context of Tesla and their autonomous driving they talk about that, but it's not specifically about that. There and there's a little bit of the history of neural nets as well. In here, so this person was very knowledgeable.And goes pretty deep technically. So I wouldn't listen to this one on three Xs I'm saying. Anyway, give this a listen it's kind of interesting and yeah. I think it's kind of fun to broaden your understanding. I know that I'm primarily a UI JavaScript kind of developer but yeah. I think that it's good to expand your horizons. So give this one a listen and I hope it does that for you. Okay, take care.
https://twitter.com/kentcdodds/status/1381453907730128900?s=20 Hey friends So last night I tweeted this TypeScript question. When have you used never in a production codebase links to examples welcome? And I failed to mute the conversation and so I ended up waking up the next morning with tons of notifications, which was great. So many people were happy to share and I just wanted to share with you a couple or the like basic themes of the different examples that people shared. So the first is discriminating union. Oh and by the way, if you've never heard of never before the basic idea is it's a way for you to say.Hey the type script type checker as it's flowing through the types of my application, it should never be able to hit this type. So it's like those situations where you like this should never happen. That's basically when you use never. So anyway, the first is discriminating unions and a common example for this was if you had a component that could take a variety of different props. So an example is a component that could like draw a shape so you could be rectangle or a square or a circle and depending on the type of shape you want to draw you're going. To have different props And so square will have a width Rectangle will also have a height in addition to that. And then circle won't have either of those it'll have like a diameter something. So the you know, the discriminating union's use case for never would be when you union those props together you want to be able to say hey when it's a circle I never want to have a height or a width and when it it's a square. I never want to have a height because I just get it from the width and I never want to have a diameter because it's not a circle. In my mind,Actually most of the examples were similar to that and in my mind most of the time you're actually probably better off just making two separate components or yeah different components entirely that are responsible for doing that specific thing. However, sometimes there are definitely use cases for you know, if if you're going to provide me this prop, you also must provide me this prop, but if you provide this other one, then you must not provide this this other. So like aria described by versus already described stuff like that. So that was like the primary use case in addition.Switch out ifs and else statements this is where you can make a function that is basically they would call it a certain ever and it would return never it would throw an error. And basically your time typescript well by calling that function you get a type error. And so if you put this as the default case or something and you're not handling every case then type script is going to cause a problem for you. And then the last one was conditional types and that one still pretty hazy for me. I can't really explain it. So anyway, hopefully some of that was interesting. And I hope you have a wonderful day. Bye.
Clickbait? Yes. Hey folks today, we're gonna go with the untraditional not tech related really podcast so I got my first dose of the modern of vaccine yesterday. I strongly advise that you do the same if you are able all of the data points to this being safe despite it how fast it was produced and everything so I if if you're not if you don't get the vaccine but you're able to then you're putting other people at more and greater risk unnecessarily so just please get the,Team let's get our lives back to as normal as we can so we can work on all the other terrible things that we need to work on and focus our energy on making the world a better place and yeah just for me this first dose has been this morning. I woke up feeling like I got hit in the in the arm really hard and so it felt kind of bruised and then I felt fine and right now I'm writing around on my one wheel so I I'm not super terrible but I am feeling a little achy and that sort of thing. I hear that the second dose is work.S and so we will see what we will see there but whatever issues I have it is worth the cost. I actually did have to test positive for the virus in October but yeah just getting vaccinated clearly. I guess this is affecting me anyway so so yes, I'm glad to be getting vaccinated. I'm hoping that we can return to our regular lives as soon as possible and I hope that you get yourself vaccinated too.And we can all just get back to a better situation than we are now all right that's all I had to share with you. I hope you have a glorious day it is beautiful here in Utah right now and it's just glorious so I hope your day is equally amazing and I wish you the best of luck in all of your personal and professional pursuits because yeah, sometimes we need a little luck so take care bye.
Hey there friends, so I have a question somebody's asking on the KCD office hours channel in discord and I decided this is something that I can answer in the three minutes with Kent alright podcast, so the question is what are my thoughts on PWAs nowadays should all websites be PWAs are there const making your site's PWAs so in general or to be clear a PWA stands for progressive web application and normally when we're talking about this we're talking about something that can be like installed. You can have background notification like push notifications and stuff like that works offline, in fact Chrome recently started requiring or is going to require offline functionality to be present for your app to be installable as a PWA, so I have actually had my website installable as a PWA before and I've had a couple other a little apps or sites that I've made PWAs installable and it's kind of cool. I would caution people against just saying let's make everything a PWA because I have had some sad experiences with service workers with Gatsby in particular it was just so easy to turn on offline capabilities, which is a plug-in but unfortunately that plug-in had a dependency that had a funny problem with it and so I ended up having testing JavaScript.com install a,Service worker that would never get updated ever and so we launched testing JavaScript.com, it's like here's this is coming soon and then when it was officially launched a ton of people did not see the update and so they couldn't buy the course and it was just a total nightmare disaster. I had some frustration and annoyance with the PWA I had for my website and because people would come to see my blog and then I do an update between the last time they saw the flag and this time and so let's see old.Content and I'd have to do a notification that said hey there's some new content downloaded now and most the time people don't really care to have it offline and so it was just an annoyance so I would say that unless you're doing some offline support stuff then there's not really a great reason to make it installable and and whatever you have to have a good use case for your thing to actually be like an app and useful in that sort of context for making it a PWA, those are my thoughts on it. I hope that's useful in interesting take care.
Hey there friends. So a while ago, I wrote well actually several years ago. I wrote a blog post called a newspaper code structure where I described the way that I like to structure my code to basically make it. I don't know easier for me to parse as I come into a new file and the idea is that anytime I have some sort of block of code that returns some value or whether that be a function or a module where your exporting values and stuff. I always,Like to do the the thing that it returns or the exports at the very top of the file and the reason for this is in a newspaper article and they make it they write it so that they add just kind of a high level first and then they slowly fill in with details and the reason they do that is so or at least maybe they used to do that this way is so that you could clip the article at any point to size it for where it needs to be and it would still be coherent to make sense. And in the same way I like to make my code so that it makes sense.Reading from the top down and if you need additional details then you can dive into the function there. And so what it ended up looking like is you'd have a function and like one of the first couple lines would be a return statement and then all of the guts of the function would be in a other functions that are below the return statement. This is actually like a thing that you can do. You can define functions below a return statement and they will get hoisted the declaration and the definition will get hoisted above the return statement. So it technically actually works. So I did.The first for a long time but I eventually stopped doing this and the reason is because I I was bothered that I couldn't put the exports and the return statement at the very very first at the very very top because any time like so the the hoisting functionality I'm talking about that works for function declarations, but it will not work for arrow functions, it won't work for variable declarations. So, I'd have to just put everything in enough function if I needed to use any variables and so what ended up happening.Was I'd have a couple of variables that I define at the top and then I never returned statement and then I'd have all the other functions or in a module I'd have you have to put all the import statements at the top. Well, you don't have to those get hoisted too but it just looks funny if you don't. So I put all those at the top and then I have some variable declarations and stuff and then my exports and so what I ended up with was a return statement and the exports that were just like in the middle of all the code. So now I just put everything at the bottom and it's easier to find. So, that's that's why I made that change. This is an answer to somebody in Discord. I hope you're having a great day. Bye.
So the last question in this email has to do with how do you know why where to start testing because you're adding testing to an existing project and so most of your tests are actually writing tests for code that exists and so it's not like there's no test driven development there or anything like that. And so, how do you know like how far do I go and testing when when can I stop and say that this component is tested? Does it have to do with code coverage or whatever? And my answer to that is I actually do have a blog post how to get started with testing or how to add tests to an existing code base. Where I talk about with just kind of in general you want to start with a single end-to-end test and you add some static testing and then you add the tooling for and unit integration and then just add over time and you can go take a look at that for a little bit deeper read on that, but if we're talking specifically about I have this component and I want to add tests to it where do I start and for me it comes down to thinking about use cases more than thinking about code coverage. And I actually have a blog post ofAbout that as well. But basically the idea is I don't really care about code coverage. Lines of code is basically irrelevant. All that the the code coverage report tells me is the use cases that I'm not covering. That's what I'm thinking about when I'm looking at the code coverage report. So if there's like an if statement that is not covered then that just says, oh, okay, so whatever use case that code exists for that's a use case that I'm not testing for because use cases are all that we care about. We care about this.Code working for the users whether that be developer users who are calling our functions or rendering our components or end users who are clicking the buttons were rendering whatever. And so you want to think about the use cases that you're covering and then you weigh them relative to the confidence that you need for other use cases of other components as well as the features that you need to build and bugs you need to fix and things like that. So it really comes down to what we said before about weighing the return on your investment of time for writing.Versus features that you can work on Now let's say that you live in a world where it doesn't matter You don't need to work on features you can just totally focus on tests. There is a stopping point for sure and the stopping point is when you feel like you've covered all the use cases. Now for like open source libraries and stuff it typically end up covering all of the use cases you get a hundred percent code coverage, but for applications. I never find myself in a situation where I can just spend a ton of time on tests. I need to work on features and that's where you just need to kind of weigh, what are the things that I am going to write test for.Versus new features or whatever. Hope that helps Ciao.
Hey friends this is another answer to that lengthy email from Poeter I'm not sure how to say that but properly sorry but the question is how do you write code that can be easily tested and they go at length to explain, you know, sometimes you write, you know smaller functions and we can test those easier but ultimately like, it doesn't always work that way components typically grow and splitting them up makes it feel harder to maintain and I totally agree with that. I have a blog post called when to break up a react component.And I typically preferred don't break it up if you can help it avoid breaking up your components unnecessarily so yeah, so I prefer having bigger components but then like okay, so how do I test this it's got a bunch of use effects and whatever else in it and then they also bring up the container or yeah the like the smart and dumb components sort of thing or whatever we landed on for the macular for that but I actually never liked that pattern either. I didn't think that it was a useful.Mechanism for splitting components up or anything it didn't make any sense to me. I mean, I understood like what the rules were but the rules were stupid. I thought and never got any value out of that, so how do we write react components or just code in general let's easier to test well. I think that if you're testing from a user's perspective and focusing not on building like running necessarily testable code, but just code that's that's sensible that makes sense like there's you're not breaking things up unnecessarily and you're.Associating things across like that are in the same vertical I guess like yeah just not breaking things up unnecessarily and then you test them from the user's perspective, it really doesn't end up mattering how complicated the code within it is necessarily especially when you're we're talking about unit or integration tests where you're mocking HTTP calls that stuff as long as you have MSW to intercept requests and and mock those out and then occasionally maybe mocking a third. Party library that's complicated or something from there it's it's just rendered the thing and interact with the thing the way that the user does and then assert on its output. I never really think too much about making my code testable necessarily and maybe that's just the curse of knowledge on me just learn to do that naturally and it's something you develop over time, but it's not really something. I'm thinking about a whole lot. I guess one thing that I do is I I typically avoid doing side effects in the root level of a module and I always put those in a function and that can help make things a little more testable but in general, I'm not really. Thinking about it too much. I hope that's sort of helpful bye.
Hey your friends So I am going to for the next couple days answer some questions that I got in an email from somebody. I don't know how to pronounce this name. It looks like pejor or push actor. I'm not sure they're from the Netherlands. And anyway, they actually wrote me quite a nice email about testing JavaScript.com and just had some additional questions because the course mostly goes into the how to get things done and that doesn't get as much into like some of the philosoph well it actually yeah, we we get into that a bit. But there's no like specific lesson on how to write your code, so it's testable or whatever. So anyway, um, most of that knowledge I share on my blog. So if you go to Cansee dots.com slash blog and then type in test then you'll see I've got dozens of blog posts about testing and so that's kind of where I direct people to for when they have questions like this, but I thought I just answered a couple of these on the three-minute podcast. So for this first one, the question is what should you write tests for and whatnot?To write test for and why? So and they acknowledge that yes you want to avoid testing implementation details but how do you know that you're done writing tests for a component? So for one thing I actually recently had a question from somebody who said like should I make assertions that certain things don't show up in my output, you know, so we're asserting that the login button shows up and I can click on it but like should I also assert that the register button doesn't show up or whatever the case may be? And,So anyway the answer to this question is everything that you do in software is trade-off and it has a cost and that cost is equal for everything and the cost is your time. So how much time do you spend working on any given problem and and you weigh everything relative to the amount of benefit that you get for the time and it isn't exactly a science is a bit of an art but you generally just think okay, so I'm gonna write this test for this component and the reason that I'm doing it isn't just to write a test but it's because what I get out of writing it. To test is more confidence And so at every moment of the day or whenever you're making it a decision on what you should work on you should think okay so I could write some more tests for this component and maybe I've been working on this component working on its test or I could go implement this new feature or fix this bag or whatever. And you just have to decide okay based on the amount of cost that it takes from the time aspect versus the amount of benefit with more confidence or nice feature for more users or whatever and you just weigh those and make a decision on what is most valuable. So you're not just testing because you want to tend to. Ask but you're testing because you're trying to get something out of it. I hope that's helpful. Good luck.
Hey there friends. So today I'm going to answer a question from Lean or Leon I'm not sure how to say your name sorry but this is asked in the react hooks channel of the discord the KCD discord under the Epic Reactive category and it's talking about exercise six where we show it's it's an exercise on managing state for asynchrony, so we've got to use effect in there and stuff. And we have this status status and that is the status of the promise. So whether it's idle pending reject,Ed or resolved and we render different things based on that. And in my solution, I just do an if statement. So if status is idle, then this outsift status is pending then render this also status is rejected then do this. And that I I was pretty happy with that. But I there are obviously several different ways to do this and one natural thing that people sometimes will do is a switch statement which is what this individual suggested why don't we do the switch statement, but then they got some pushback on that. Hat from a co-worker. I think that suggested using an object instead and so you can say here's a a object that has the status value so you have idle pending rejected results and each one of those is assigned a as a property the the value is going to be the react element that should be rendered. So I mentioned that I would talk about this. So in the next version of Epic React, so if you look in this repo on the next branch, I actually switched to not only TypeScript.And but I also switched to using a switch statement Just because I think that it makes a little bit more sense in this context. Like I said, I often don't use switch statements. I prefer if else or maybe even ternaries but in this case, it just seemed to look a little cleaner and so I use the switch statement there. Definitely know hard and fast rule on that. It's just try them both and pick the one that you dislike the least. Um, but I did mention in this discord chat that it actually is really not a good idea to use the object approach for something like this. And the reason is that,Sometimes you're gonna be switching on something like in our case we're displaying a Pokemon. And if you're going to create React Elements that reference properties of that Pokemon then you you're going to be accessing properties that may not exist based on the status like if you have idle the Pokemon could be null. And so if you're even though those different properties of that object won't actually get rendered you do have to access those properties to create the React elements. So, that's why you don't want to use the object form in this case at all. So, I hopeThat's useful and interesting and I hope you have an awesome day. Goodbye.
Hey friends, just something that I've been thinking about recently is this acronym that I came up with a few years ago. It's AHA and it's pronounced aha and so that's aha programming and it stands for avoid hasty abstractions and this is actually a blog post that I wrote with some time ago and it talks a lot about how like dry do not repeat yourself as to dugmatic and wet programming which is a variant of that is right everything twice is also. Two dogmatic and more we should be more mindful of the types of abstractions that we create and and I talk a lot about in the blog post, which I suggest you go take a look at but one part of this and is at kind of the micro level and that's what I have been thinking about recently just today. As you're working on a new feature or something is really really often in my programming at least I'm working through something and I start I'm thinking about how I'm going to implement something and I instantly decide okay, I'm going to need.A function that does this And so often that ends up being the wrong decision I end up making and especially with TypeScript actually. This is a big pain because then you have to there's just a lot of boilerplate with making a function. But even even not without TypeScript, you have to think about okay, what are the parameters what order are they going to be in or is it going to be an object that AD structure? And it just adds a lot of stuff that for code that you don't even really know what it's going to look like yet and and on top of that if you decide oh actually this function needs to change like weWe just add a lot of extra work and thought before we've actually written the code just by making a function for this thing that we think we might want to function for where in actuality. I find I'm so much more productive if I just start by writing the code and inlining as much as I possibly can even if that means I'm copy pasting from one part of the code base to another and just in line everything as much as you can make a big long function. And then before you commit at that point, you look atThe code that you've written and you think okay, so now what are the abstractions that I see now that the code has been written? And so, I find a lot of my problem comes with when I try to abstract the code that's not there yet. And I find a much more productive if I abstract the code that exists after I've written it. So anyway, hopefully that's helpful to you next time you feel the urge to write a function for code that doesn't exist yet. Maybe take a step back and write the code first then make the function. Have a wonderful day.
Hey friends the future is the edge We've got the now-fight edge thing CloudFlare workers things we want to be able to deploy our code and have it run as close to the user as possible. Before it's always just been static files that you put on a CDN like Akamai or Cloudflare or fastify or something like that because that's really easy to do. You just you deploy and then the provider will send these static files all around the world to their servers and and then users can get those files really quickly, but anytime you needed to get data you had to go to wherever the data.To the center was. And so that like pretty much doing a server rendered application would require that at some point you're going to be going to to have to go to some central place to to get that data. And so it's going to end up being slow. And like in particular for server side rendering stuff it. It's not very useful unless you are doing stuff with data anyway. So things are changing. We've got these contour workers, so you can actually run server rendered.Staff or server side logic on the edge. So close to the user and then we have fauna DB and I'm sure there are others like it that's the only one that I know of where the data lives on the edge as well. So when you do a right to the database Fana will push out the the right to all of its CDN clients or whatever all all of its servers all over the world. And so then you're running compute on the edge and your data is right there on the edge too.And so it's just outrageously fast and it's really cheap like very cheap. Sometimes free if it's a very small sort of thing that you're building, but you're latency is going to be very like I'm looking at Cloudflare right now. It says your actual latency is 16 milliseconds. It's like that's that's my latency on this page. I just tested again. It's 15 milliseconds. It's outrageous. Oh, how fast this stuff is? And so the future is the edge. We're going to have data on the edge. We'll have compute on the edge. It'll be very.Very very fast. No cold starts cold starts are you know here on the clock for our workers page their support for zero millisecond cold starts. We're it's it's basically free it's outrageous and it's an exciting future. I'm not saying that you need to rewrite your app so that it works in a cloudflower worker or anything but I am saying that this is kind of the endgame for remix. It's a definitely a target for what remix is trying to do and I'm super here for it. Yeah. I hope that's interesting. Have a good day.
What is up friends so this is another one in the real world programming analogies segment I guess so actually a long time ago. I wrote this down as something I could do for a blog post but you know TV remotes and how like you either have like 30 different remotes to control like your TV and the receiver and the the Chromecast, you know, like all the different and remotes that you need for that it's a disaster or you can get a universal remote. And what's interesting about universal remotes is that they're to make them actually universal first of all there's a lot of work to make it work with all these different technologies, but then they're like 20,000 buttons on these things and nobody knows what they do because they have to be generic enough to be universal and I was and and so like either one of those is isn't great but it just made me think about abstractions and trying to make your stuff overly useful or satisfy at. Every use case and actually I was listening to syntax recently and I think it was last week's article our podcast where Scott mentioned that he was trying to use some I think it was like an authentication thing and I think it's like account JS or something like that anyway, it supports like pretty much anything that you could imagine from a backend perspective and things and he realized that he had to do just a ton of work to glue everything together and only ended up on using like 10% of. What this abstraction offered and realized that he could just write that 10% himself which he did and ended up being in a much better place and I have definitely experienced similar things myself where things are just so generic that it is basically not doing anything for you and so like there you're you've got both both sides of the coin and coin so like over modularity is a problem where you know, it just does so much that it's hard to make things or like you have to do a,Lot of work just to make it work and then you end up not using all of the features that are supported and on top of that maybe the library is going to the client side and so it's really big and that's a problem but also bad abstractions are a problem too and and so like making something too focused on a specific use case may not make it useful for general solutions or general problems and so yeah, like it just was something I always thinking about over modularity can be a problem just be careful of that and I hope that. Is interesting take care.
So one thing that I do, you know, how you like you do something just you've done it forever and then when you show it to somebody they're like blown away like, oh man, what a good idea, whatever nobody is said that to me on this one but I thought I'd be one of those things that um that I just do it naturally in and you might find it to be useful so in my global git ignore for my machine. I have a pattern for ignoring anything that includes the text dot ignored dot and and so then I can create a folder.That's like temp dot ignored dot staff or more often I'll create a file that's like temp dot ignored dot js and what this allows me to do is I create a file like that within my project that I just want to play around with stuff and I don't want to have to install all the same dependencies in a different project or whatever and I don't want to mess up the other files that I have in my project and then I can mess around with things and I do this a lot for interacting with third-party APIs, I'm just trying to learn about like what's the code that I need to write to consume? This API and transform it into whatever I need it to be and then forward that on to the rest of my my code base and and then adding types to it and everything and so yeah just having the ability to quickly create little files that will be ignored by git is really quite useful and and files within the project so I can import other files and things and if I want to write it all in typescript then I can use TS node to run it but normally I just do it in JavaScript because often script. Just kind of in the way there especially since I configure type script to be unstrict mode and everything I'm just rapidly iterating over some code and then when I'm all done with that, I can copy it into where it should be in my project and add types to it and everything like that so anyway. I think that it can be useful to have a little kind of a playground sort of area for you to to experiment with different ideas and stuff if you want to take it to the next level there's quokka by Wallaby JS and I do have quokka and I use that sometimes but what I'm interacting with third-party APIs, I want. To be explicit about when I'm rerunning the code and so yeah having just a separate file for that can be quite useful. I've done this for years and maybe that'll be interesting or useful to you hope you have a great day bye.
Hey friends, so I am at ski resort in Utah right now and they have this kind of a funny story that in the bathroom they have the urinals covered up like every other one covered up for social distancing and a few weeks ago when I brought my son up here he needed to use the bathroom and all of the and he's he's kind of small so normal he just uses the pot but all of the those were being used and he really needed to go and so I was going to. Have him use the urinal but they covered up the only small or short urinal so they because they covered up every other one they just happened to cover up the only short one and so I I ripped off the garbage bag that was tied on to it and so he could go but it just made me think like the the this is has something to do with like accessibility and the importance of diversity in your team because I imagine that the the person who is assigned to cover those up like they didn't tell them which ones to cover up they just covered it they chose one and they did every other one and it just happened to cover. Up the the shorter one but if they'd been apparent then maybe they were a parent of small children or something then maybe they would have thought oh let's make sure we keep this one uncovered so that smaller or shorter as smaller children are shorter people can use this one and that's the sort of thing that you just miss out on if you don't have a diverse team so I I think that is like it's kind of a silly example, but it is an example of a situation where having a broader set of experiences on your team can expose you to more needs that. Your users might have and so yeah those are some of my mind this morning. I just thinking about the importance of diversity. I hope that is interesting and useful to you and I hope you have a fantastic day and we'll catch you on the other side.
Hey friends, so I was just working on something for the last hour or so and I got to a point where I decided, you know what this I probably shouldn't be doing this like it was an optimization basically. I wanted to be able to change content on my site, so I whether it be a blog post or the about page or something like that, but not actually trigger a redeploy and I'm using GitHub actions right now for this site and there are ways that you can determine okay, what was the last successful deploy? And what should be the you know what files are changed between that deploying this one and if they were only content files then just don't deploy them. And so, this is absolutely possible and I was working on it and I spent about an hour or so working on this and then I finally decided hey, you know what? I don't think that I need to worry about this right now. It's an optimization so what if I'd redeploy on a content only change? Right now, I'm just trying to create the site in the first place. I'm not I'm barely even deploying. So yeah, I'm trying to solve a problem that I don't have and it's very. Possible that when I'm all finished, I'm gonna switch from GitHub actions to to Netlify or something completely different and yeah, it just seems to me that this is way premature and I should be working on other things just to get this site up and going before worrying about you know, am I deploying unnecessarily? So yeah, that was just a thought that I wanted to share with you all just make sure that you when when you realize that what you're doing may or may not be used.Full and there are other things that you could be doing that would be more useful then stop doing what that thing. And I just made a branch and committed to changes that I made I pushed that branch up and so I'll have that code if I ever need it but I I don't think that I will honestly but in any case I've got it there and I can shift over to something that can provide more value and more of what I'm looking for. So anyway, I hope that's helpful to you and I also hope you have a splendiferous day.
Hey friends. So today I was working on a little problem that I had with Create React app. So if you don't know Epic React is a combination of a bunch of React workshops that I have given many times in a life setting and it's a recorded version of kind of a live workshop that's kind of the feel. Anyway, all of the workshops there are powered by create react app under the hood and I've got a abstraction on top of that to share a bunch of code between all these different workshops.So I am in the process of moving everything over to TypeScript and I want to be able to have two different versions of TypeScript or of texture configuration for the exercises versus the final version. So I want to make sure that as we're moving everything over to TypeScript if you don't want to do TypeScript, it's as like easy as possible or if you've got very limited experience or no experience with TypeScript, you should still be able to get a lot of out of the workshops without having to have a bunch of red squigglies all over the place with their messages that you don't understand. And so,I don't want to have strict mode on of course for the those exercises because that would be against that goal. But I do want to have strict mode on for the final version of all the the exercises so I you know, because there's good reason to have strict mode and and it kind of helps me as I'm working on it to make sure that I'm doing everything the way that you probably should in a real application. And so, unfortunately with Korea react app if you don't have the TS config set up proper well here let me back up so.You can do this by having using project references and so you have just your main TS config that references other TS configs and then those can include an exclude different files. So I can get that set up but the problem is that in create react app if you're root TS config isn't doesn't have all the right properties then it will fill those in automatically for you and that messes up the references stuff. So, it just doesn't support references which is a big bummer. I made an issue about this. But what I did for,The foreseeable future unless create react to app ad support for references is I used this package on NPM called Patch Package and it allows you to install all of your dependencies and then you make a change to one of the files in your node modules and then you run the script and it will generate a patch for you and then you just set a post-install script in your package JSON and it will after your people install it it will apply that patch. And so, I was able to make a small change to create react app to support this. So give patch package a look it's pretty cool. It's kind of interesting. IHope that was interesting to you and I'll talk to you later.
© 2020-2025 Ivy Podcast Discovery LLC
