Our React Wish List

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here JS Scott Tolinski

and Wes Bos. Welcome to Syndaxes. This is the podcast with the tastiest web development treats. Today, we're gonna be talking about our React wish list. These are Wes sort of been keeping tabs on, like, things that I wish that React had or JSX had or, generally, the community in general. I put out a tweet as well. I got some really good insights on that. Today, we are sponsored by 2 awesome company. First1 is DevLifts, which is going to get you the developer fit. Their entry level plan is now free, which is amazing. We'll talk about that partway through and FreshBooks, which is cloud accounting. As always, my name is Wes Bos, and with me as always is mister Scott Tolinski. How are you doing today, Scott? Hey. Doing good. You know, hanging out, doing my GitHub, About to launch the new LevelUp Tutorials video player, which has been a, lot of fun. Slick. Thank you. Yeah. It's using Player. Js. It's using Mux for video hosting.

It's a very nice and modern solution that I've been looking for for a long time, and we have an episode coming up that I've been planning for a little bit about video on the web and, off of the the ins and outs of video on the web. Because let me tell you, I was looking to move our encoding to a different platform, move our video hosting to a different platform, you know, wanted to just get everything a little bit better.

And it is an interesting world that we may not tend to dive into too often, especially when platforms like YouTube make it seem so easy. Right? Yeah. Yeah. So that would be a nice little topic for future ones talking a little bit about Node only Mux and why I chose Mux. Maybe we could have some of the Mux folks on here. Yeah. So let's get into it here. I do maybe wanna preface this episode just to let anybody know because I I'm sure there is going to be a substantial amount of people who disagree with various aspects here and, specifically, React team members. If you disagree with us, that's cool. I I would assume that most of these things we are aware of are probably not practical. Some of them definitely are practical, but I'm sure there's a a certain percentage of these things that will make some people's eyes roll whether or not you are a contributor to React or whatever. But just know that everybody has different opinions on this stuff, and these are just sort of our opinions and things that we've gotten from the community.

So, try try to keep an up in mind with some of these, especially as we we talk about them. I think it's gonna be real fun, and I think the, premise of this episode is intended for this to be a fun exercise and not a, not a contentious one. Do you know what I mean? Totally. I think in the past, like, if if you made me make react, I woulda screwed it up by now. Yeah. Right. Exactly.

A lot of the times, the solutions that react comes out with is because they know better than I do for my own for my own good. So this JS, like like like Scott said, no shade podcast, but these are just things as a developer that we would love to see either in React or like, a lot of the things that we're gonna say, people are gonna say, like, just use this plug in. But a lot of them are gonna be like, well, we would love to have some sort of first class support for these types of things so we don't need to bring in a plug in or something like that. Yeah. Right. Exactly.

I think the number 1 is I think we both can acknowledge that React, a lot of the decisions that it makes Yarn from the standpoint of it wanting to remain flexible. Right? It's always had the the sort of idea of flexibility as a strength. Right? The fact that the community can come in and do a 100 different state options is a is a strength. And at the same time, that strength can also be a weakness because what it leads to is it leads to some situations that either have a 1,000 different solutions or might not have a clear solution.

So I I think that maybe is an initial preface as well. Now that we're done with the endless amount of preferences, preface says, let's get into, the first one, which is going to be Node of the features that I've been wanting forever and ever and ever JS the ability to delay the unmounting of a component easily because, yes, there are ways that you can do it, right, easily, for specifically for things like animations. Like, how great would it be Wes you just say, hey. This component, you you take, you know, whatever, 1 millisecond here to unmount. And while that's happening, maybe I can process some quick and easy animation stuff. Because right now, the solutions end up being, like, duplicating the component.

They were having both components mounted at once and then fading out while 1 fades in and the other 1 fades in and trying to time it all. And it usually is up to the animation library author to solve that problem that I think should probably be a React solve problem. But I am very aware through conversations that I've seen on this one that it is it is a deceptively difficult problem with how React works. And it's not just as easy as saying, alright. Here's your delay field right here. Right?

React doesn't give you any animation stuff. Early on, they had, like, a animation package. I think that they it's no longer the official one. They sort of gave it off to to somebody else, and there's certainly no end of, animation things animation packages out there. But if you take a look at Svelte and Vue, animation's, like, all first class in those frameworks. So I know that they're sort of just saying, like, maybe it's not for us to do, but I certainly would love to see at least some very basic animation things added right into it. And that also like, you think back to jQuery, people love jQuery because of that, because it just comes baked right in. You don't need to go reach for another huge

animation thing and have providers and whatnot. Just just let it work Scott out of the box. Yeah. And and it's funny because I wouldn't even necessarily getting into animations overall as a whole, but it would be nice to have that baked in support as long as it was nice and elegant. Because there was something really special about in Scott to bring up my course course because I don't wanna sound like I'm marketing here. But, in my latest separate course, we did, like, an animation unmount per route or even, like, a component that flies and unmount. And it was as simple as just adding a it was like a literal transition colon fade on the component.

That's it. You didn't have to write any CSS.

You didn't have to write any JavaScript. You didn't have to you just put that one little liner on there, and it handles mount. It handles unmount. It handles anything you want. Next one we have here is, like, just React suspense in general to release. So there's a there's a big update to React that has been coming for, like, probably a year and a half, 2 years now, and it's going to handle being able to suspend components while you are doing something. So most likely, that's going to be data fetching, and you can stop the whole thing from rendering for a certain amount of time. And then if that goes over, you can show a loading screen. We have a show on it we did well over a year ago on what React suspense is, and I just don't I I have no clue where it's at. Oh, I think they might be getting I think they might not ever be releasing it. Did you see that tweet from Dan about it? No. What? Okay. So suspense in general? Yes. Let me see if I can find this. Alright. So Scott and I, we just paused for, like, 5 minutes, and we tried to decipher these tweets from Dan Abramov.

And we're not sure what they mean. Obviously, they're they're second guessing whether suspense should be a thing. They're talking a lot about how sir the server side rendering needs to be first class citizen.

So maybe they are looking at getting more into the server space and sending diffs on over.

It it seems like the reason why there Yarn is delays is because maybe there's a or reimagining or reenvisioning of how things are going to work or maybe some bigger thinking going on than just say, alright. We're just gonna finish this and roll it out. Right? Because once something's rolled out, it's, you know, it's you gotta support it. You have to maintain it. It's a big decision, especially with a platform like React. So, obviously, with a feature and something as big as is the implications of this JS that they should take their time. Right? Absolutely. It is one of those things that we would like to be solved. I know me personally, I work quite a bit with server side rendering in React, and it is not the most fun process having to rehydrate. And then whenever you hit issues in rehydration, it's difficult to solve. Like, sometimes I have issues where, let's say, 1 div, like, doesn't close correctly or something, or, like, CSS all of a sudden isn't applied to the the section correctly. And if you look at the HTML, it's malformed.

And you say, I wonder why this is, but it's coming in from a server fine. It's a hydration issue. And sure enough, the hydration issues are definitely going to be, you know, user caused errors, but it's not always clear why these errors are happening or how they're happening or how to fix them. And then there's that old good old friend that is the element div was expected to be Node div or element div was expected to be a div, but was found to be a header element error that you get during rehydration Wes the rehydrating elements are not matching what's on the server Node. And that one's extremely although they've made it better, it doesn't necessarily always let you know why it's happening. It lets you know that it is happening, but it tells you very little about why it's happening. So server side rendering in general on React definitely seems like it exists, it works, but it definitely isn't as seamless, smooth, and easy as it could potentially be JS we've seen from platforms like maybe Next. Js or even not in the React ecosystem, Sapper or something like that. Next one we have here is

file based components. A lot of stuff we're saying is is that Svelte and Vue have done a a really good job at it. So being able to put your components, throw in a style tag into a single file. Right now, React is very unopinionated about how you should lay things out. And and components, you can put multiple components in a single file. They have no opinions on how you should use CSS other than you can pass a style prop to any component. But with a file based component, you'd be able to have things like scope style tags. So when you have, like, 1 component

Vercel like, per file Scott of, like, file based component, it does kinda inherently keep things a little bit more organized because you can't all of a sudden have a bunch of components in 1 file. It's Scott of like automatic stuff. It also makes some of the naming of things automatic.

It doesn't make as much sense in the React Scott context as it does others because, okay, you have a function that functions the name of the component. The function has a return statement. Everything happens within that function. But what what would happen if you were to all of a sudden and keep in mind, this is Farfetch. Eliminate that function and just have the script stuff happen as in the file, and then you would have the the JSX be automatically returned. Granted, I don't think any of this necessarily works in the React context as is. If you were to just say, alright, let's do view single file component templates in React. Obviously, there would be a lot of, reimagining that would have to happen for that to work. But I think there are some some things that it would be low level stuff if you just kept react as is and just had alright. You put a style tag at the bottom of your file, and all of a sudden Wes have Scott CSS rather than anything else. And I think those are are, like, maybe the more of the realistic changes you could see here coming from something like this.

And to me, it's not like a big big deal or a big thing, but it would be kinda nice to have that kind of support rather than right Node, we have, like, 800 different approaches to this, whether it is, creating a style component and then wrapping your files in a component or using, whatever Vericel's solution was or using importing style JSX or impure or importing CSS or whatever. Yeah. Just being able to say, alright. This CSS file is associated with this component. Specifically, it will load on this component, and then it's going to be scoped to this component in a single file would be really nice.

Next, we have prevent default shortcuts.

So very often, you have a function. We talked about this a couple episodes ago. You have a function, and when somebody clicks on a button or submits a form or something that has a default on it, you'll have to both run that function as well as prevent default on that element event. You can do this a number of different ways. You could just pass the event to your function and do it inside of that, or you could do, like, a little inline arrow function right outside the on click handler, or you could have 2 different separate functions.

The first one that does the prevent default and the second one that calls the actual function.

So those are all kinda like meh.

And it would be awesome to have just, like, on click.

And, like, I know Svelte has a cool syntax that allows you just to prevent the default and then run the the the function because that's such a common thing to do. I think that should it'd be awesome if it was built right into React. Yeah. How many times have you had to write prevent default when dealing with the form in React? Just about every time. We'll talk a little bit about more forms stuff in a minute here because forms in React in general are just really not elegant. They're just bulky.

Next one I wanted to just this this is a quick little bug here. Again, this JS goes along with server side rendering. When you use server side rendering, it turns out, use layout effect just flat out doesn't work. Right? Because, well, there's no DOM to worry about. However, it just breaks. So what you end up having to do every single time, every time you wanna use a use layout effect in a server side rendered React app, you have to use your own custom component called the well, the most common one is use ISO layout JS the most common naming of this. But it's it's like, either that should be built in or the use layout effect should have a case for that Wes should just work with Vercel side rendering. Because having it just, like, not work isn't really super ideal for anyone trying to pick this up.

So let's take a quick break to talk about one of our sponsors today, which is a ESLint. Now you may recognize DevLift as being one of the very first sponsors that we ever had on Syntax. So, Wes, Wes, do you wanna talk a little bit about the Devilist's plans they have going on right now? Yeah. So you've you've heard them sponsor on the podcast before. They're developers who are out there to refactor your body. You know that developers probably aren't the healthiest community out there, and they, in the past, have had a bunch of really cool plans. And we're here today to announce that they have gone first, they have the fit start plans, which are 3 different types of plans. You have lean, body weight, or strong.

And what they're gonna do is they're gonna deliver you workouts in a spreadsheet format emailed every 4 weeks. So, basically, you Scott. You can get them in your email. You know exactly what to do. You go to the gym. You open the spreadsheet, and you just do what it says in the spreadsheet. And they are making those free, which is awesome.

And you can get those at devlifts.i0.

And then they have brought back their premium plans, which are a onetime purchase.

This is actually what I went through myself. So, it's an 8 week plan that's tailored to what you want. So it's a $199.

You get 50% off for being a syntax listener with the code syntax.

And when you pay that, you sorta fill out a form, tell them what you're hoping to do. Are you looking to get stronger? Are you looking to lose some weight? Something like that. And you tell them where where you're at. Like, I told them I was going to a gym, and I have access to all of the equipment. Other people say, I don't have access to a gym. I can only do it at home. And right now, almost nobody has access to a gym, at least in Canada. So you can sort of tell them, like, where you're at and and what you wanna do, and they will give you a tailored plan for what you want. You also get what you should be eating and sort of diet and nutrition that you should be going on as well. So check it out, all of the plans. You get Slack access as Wes, so you can get a really cool community of other developers who are looking to get in shape as well. Go to devlifts.i0 and use the coupon code syntax for 50% off. Thanks so much, Devlifts, for sponsoring.

Cool. So let's keep this moving here. This is one that sort of gets in into some just higher ideas about React. There's really just that again, their flexibility and freedom over maybe sort of rigidness.

And some of this, to me, comes down to the lack of, like, recommendations coming directly from the React team because they don't wanna officially support something. Right? They don't wanna say this is the official way because everything's coming in from the community. But you know what? I'd really love if there was, like, a React recommended hooks package. You know? Like, here are the recommended or even just a repo of recommended hooks because sometimes you do see a lot of, like, spicy threads on the Internet saying, like, why are all these React people doing these things this really crappy way? Well, it's like, well, you know what? I mean, maybe if there was a little bit more more like, these are the specific ways to do this. Right? These are the official, unofficial React hooks. Right? And I I think about this all the time with, like, how many thousands of used fetch hooks out there are there? Like, would it really be that hard for there to be an official used fetch hook that does all this thing and if you need, like, a more complex one for yourself to use it? I don't know. To me, it just seems like there's an opportunity there for more guidance, essentially, on on some of these practices.

Yeah. I agree. And I I realize that it's it's you can simply just Npm install it and get it going, but it would be nice not to have to make a decision as to which Node you would wanna use or even have to to stop and break your build and install it and get going just for the super common things like fetch, set time out, set interval.

Those are those those things are part of JavaScript.

And if there's no, like, way to use them without writing a super custom hook in React, I think that they should at least come with especially now, like, they should come with it because, like, now that we have tree shaking or whatnot, if you're not using them, then they're not gonna be added to the build at the end of the day. Yeah.

An important point that you made there was just not having to make that decision. I mean, we Node, as developers, that decision fatigue is real. Like, it is very real. There's times when I get done working, and Courtney asked me a question about, like, dinner. I'm like, I cannot make 1 more decision today. I've made so many decisions about so many different things that I'm just my brain is fried for making decisions.

And so while this freedom and flexibility is great, it also can wreak havoc when you're you're having to, like, research 10 different state libraries just to pick how to do global state. Right? Yeah.

Next one we have here is a good form strategy to bind inputs to state directly.

I know that there's there's libraries like Formek, but even then, you have to set the value. You gotta set the change handler.

You gotta do all this stuff. And then in order to get an input tied or bound to a piece of Scott, and I find that always to be not an issue, but, like, I find myself just going like, I have to now write this, like, I don't know, 10 or 15 line hook in order to bind this data to to state. I would love if it just bound it directly to state or if there was, like, some sort of prop where you could specify a handler and then it would map that to state. I I realize it reacts a little bit more explicit, but something around making forms easier to deal with would be awesome.

Yeah. It is difficult to use a platform like Vue, Angular, or Svelte and then go back to react for forms because I instantly want to just shut the project down when I start having to write, like, a couple of use states or use reducer when, like, it would be really great just to have this auto bind JS variable to this this thing when this input changes and get to, like, essentially feature parity with actual HTML inputs to have the, you know, the input value binds. Now I grant I I understand, you know, forms and React. But to me, again, most of these form libraries that come out, they don't make the API really that much simpler. And at the end of the day, a form shouldn't really be that that difficult to write. And I think that it can hang a lot of people up. Right? When they first start typing in an input in React and nothing comes out because you haven't updated the state or all these little new things that are are are just make learning React difficult for people. I think forms is definitely one of them, that can just be painful. And it also just isn't I don't Node I sometimes my views on, like, terse and beautiful Node, quote, unquote, beautiful code in my mind, my personal opinion of aesthetic beauty within code, get in the way of making things actually real world usable and robust. I sometimes look at an API, and I think, why can't this API be way simpler? Not, like, really considering all of the edge cases that many of the people who are developing these things actually think about. So I realized that. So next one here is going to be one that's probably not going to happen, but it's sort of the promise of React Native web, which is sort of like do you ever see the movie Street Fighter? No. No. I haven't seen any movies. Well, I figured as much, but you've surprised me sometimes.

So there's the the video game, Street Fighter the game, and then there JS a movie, Street Fighter the movie Bos off of the video game. And then there was a game, Street Fighter the movie The Game, which was a game based off of the movie. And and so it wasn't actually based off of the game. It was a game based off of the movie, which is initially based off of the game. They just did this on how did this get played podcast, so it's fresh in my mind. But that's what it reminds me of, React Native Wes. It's like React Native web is the web, which is based off of native, which is based off of the web for React.

Would it be really cool JS if, like, knowing what I know about React Sanity, I've done a couple courses on it. This is not possible, but it'd be really cool if you could write once deploy everywhere. Hey. That'd be cool. I know there is things like JavaScript that that make that nice and easy to or easier compared to maybe React Native because React Native is not trying to solve that problem. React Native is trying to let you learn the concepts of React and use those skills to write native apps. It's not trying to be a write once to play everywhere solution. But React Native Wes is trying to be a write once to play everywhere solution, and it'd be kinda cool if React Native web just sort of worked with devs and whatever.

And, yeah, I I have no practical means of actually expressing how this would work in the real world. And I say this as a fantasy of mine. It would be fantastic if you would just write your app in divs and stuff, and then React Native would say, oh, let me turn them into views and whatever you need. Next, the one we have here is compile time directives.

Someone I I have never I never heard of this. Thought of this or seen this before, but it's pretty cool. So someone linked up this directive x package, which gives you directives, which is a fancy way of saying, like, an attribute or a prop on a component for doing things like repeating.

They have this, like, x repeat.

We know that React doesn't have looping, and it doesn't have if statements in it.

And x repeat will attempt to fix that for us. So it will give us looping and give us if statements, which is kinda cool. So, like, if something is logged in, then go ahead and render out the username.

And I'm assuming what happens is this is a babble plug in, and then yeah. It is. And then under the hood, I listen to one of our podcasts.

I said under the hood, like, a 100 times. I have to stop saying that.

So behind the scenes Oh. What happens JS that it just compiles it down to whatever the equivalent is in in React world. So they have repeating if statements binding.

Oh, it it binds it. It does the this dot bind to this. You Node? It'll automatically bind that. That's not so much of an issue anymore now that we have hooks. Because this well, this library we talked about before the recording the show, it hasn't been updated since 2018. So

I I don't know what this library if it works in a in a React Hooks world or what it would even like, but I thought this was really interesting.

I kinda wish this was an active project, and people were doing some kind of things with, like, very template syntax y, which we'll talk a little bit more about when they hit the JSX section of this. I thought this was fascinating.

I think this is really cool, but I would not use it until it's, like, a standard thing in React because, like, someone's gonna come into this project, and you'd be like, oh, yeah. We use this weird Oh, yeah. Plug in. This? Yeah. It's that's the unfortunate thing is, like, I don't wanna use the same thing with, like, in JavaScript. If something is not at least, what, stage three or something, I don't wanna use it just because it's not really

officially supported just yet. Yeah. I learned my lesson with decorators. I think a lot of people did.

I I had a really great flow going with decorators for, like, Apollo queries, and, like, it was just so nice and fantastic.

Yeah. Now I had to rip them all out. I started hitting Babel issues and later versions of Babel, and there's the they went back a stage or whatever. I was just like, alright. Okay. I'm I'm not gonna put my future on decorators here. Another thing I would really like to see would be, we got a couple people mentioned this in the Twitter thread.

And this is something again that comes out of the land of view in Svelte, which is the idea of a Scott. And Node ESLint kind of takes the place of children.

Now the the reason why a slot is maybe a little bit different than a a children situation would be that you can have named slots.

So instead of just being children or, you know, children, the 2nd item in an array of children kind of thing that you might have to do right now with when you have multiple items as children. You would actually be able to pass things in into specific quote unquote slots, and then that would pass them through. And then in the next template, you define the slot and and potentially the name of what the slot is. And then that way, it just makes things a little bit easier to read and explicit in your JSX or whatever would be in the current Vercel that's in your, you know, view template and language or whatever. The concept of slots to me is a little bit more readable than the children function as is. Yeah. That seems pretty interesting as well. The so there's a lot of stuff here. People are gonna be like, why don't you just use Svelte or or Vue then? I think the answers to a lot of these, like, if you're listening to this episode and your 1st inclination is to say, hey. Why don't you just do blank? It's because we we know we know that you can already do workarounds or have, you know, easier versions for some of these solutions. We're very aware. I think this is sort of like a,

you know, like a a It's a fun thing. It's a fun it's a fun little exercise. Yeah. Totally. Alright. Let's move on to JSX then. So JSX is technically not part of React, but almost everybody uses JSX and React together. So what is our wish list for JSX? Well, the big one is remove the attributes that don't line up with regular HTML. The 2 big ones are HTML four and class name as well as the camel casing of attributes.

I think it has to be camel case in React, whereas it doesn't matter in HTML. Basically, just line it up perfectly.

Apparently, the class name thing is fixed. Somebody was tweeting us that. Paul Henshall.

Paul is a really, really excellent developer.

He worked on Paranoid Android for those of you who ever rooted your Android phones back in the day. That was one of the the bills I used to run all the time on my Android Vercel. And then he went up, and he wrote React Spring, which is one of my favorite libraries too. He does a lot of 3 d stuff now with React 3 Fiber. He just works on some really amazing projects. So follow Paul Henshall if you don't already. We'll maybe link to his Twitter in here. That's awesome. So he said that you can just use class because for the longest time Wes had to use class name on an attribute, and now Prettier corrects it, which is great. But it looks like we will just be able to use it in React as of React 17.

Not sure about HTML 4 and the other ones, but that's certainly high up on. And there's certainly reasons why they did that, but I don't care. I just wanted to be the same as HTML.

Yeah. I think for me too, it's a lot of these things end up being like, again, here's these solutions for them. I don't care. Here are the reasons why they have I don't care. I would just like JSX to be a bit more of a templating language and less of, like, trying to be too close to JavaScript or too close to React. Again, that's some of its its strengths. But there are so many nice little things that could happen if it were just to embrace the templating language aspect of things and maybe make the code a little bit readier more readable occasionally.

And, again, aligning it dead on with HTML would be my my number 1 on the wish list just because I have had most of my experience in my career writing HTML and, maybe PHP before that, but HTML specifically that like, now that I'm having to make all these changes to how I write HTML, it feels very weird to me. And, maybe that's just a dinosaur brain talking, but definitely feels weird to me.

One of the thing that I would really like is to, not have to bring in React if you are just writing a JSX or TSX component. I already do this with a babble plug in called, React require, which is what Next. Js uses, I believe. But React require will basically say, hey. If this is a TSX or JS file,

don't worry about importing React. We got you. Yeah. The so this is coming. So the thing that transforms JSX into JavaScript is called, it's a Babel plug in called transform React JSX, and the it's already been merged. So the functionality is there that if it detects JSX, it will just import React for you because that was always in that's one nice thing about Next. Js is that you can just start typing JSX, and, of course, I need React in in this component. It's a entire React project. Why do I have to import it? And that is no longer going to be a thing, which I'm gonna see if I can sneak this into my next course.

Because how awesome would that be if I don't have to spend the first, like, 10 seconds of every file importing it? Or

you know what I mean? It's it's it's it's a bummer. Yeah. I I use this React require plug in to great success. I also kinda take liberal use of another babble plug in, which is is not super related here, but tangentially related to what we're talking about. I use one called import globals for things that, like let's say, in, okay. For instance, there isn't going to be a bundle of my code that ships without a GQL because we use data just about everywhere. Right? So, well, why not just make GQL available without having imported ever? So I have this import global's babel extension that allows me to say, hey. Automatically import GQL JS well as a style in every single file as well as link because I don't wanna import warp crawler links all over the place. So I I actually make somewhat liberal use of this specifically for plug ins and packages.

It's import globals in the plug ins.

Again, these are these are ones that are going to these are dependencies that will show up in every single bundle that I use. Babble, plug in, import, globals.

Uh-huh. And, again, I I use it for GQL. I use it for styled from styled components. I use it for Tolinski.

It's funny. I also use it to import f c, which is from React for my TypeScript stuff because I don't wanna have to do react dot f c and just because I'm lazy. I can type f c if I wanna have a type for a functional component.

So there's a lot of lot of little things here I use that for, especially if the code's gonna be in every bundle anyways. This is not a very popular plug in. This is a hot tip you're dropping here, Scott. I you know what? I come from the world of liking a little bit of magic, and some people really shudder at the fact that, oh, you could use style without importing it? Well, I don't care. I'm never gonna have a variable named styled because I use styled components just about throughout my entire site. So I'm never gonna have to think about that. So, sure, it's not something you wanna do in every project or whatever. But for me, I really, really appreciate not having to import something.

And I know the 1st comment is gonna be, well, you can set up auto import. Yeah. I have auto import setup. I still don't wanna do it. I don't care. Okay? I like the simplicity.

Another one that we often talk about on here is better conditional syntax because it's not always super readable to do variable ampersand ampersand whatever.

And and there's definitely some some caveats here, whether it is using ternary operators or or using the ampersands or whatever. It would be nice to have some explicit if statement. Sometimes it's just visually nicer to see the word if else whatever in your code rather than ampersand and question marks and whatever.

Yeah. I agree as well. The the if statements and the the looping we'll talk about the looping in just a second. It's they're dearly needed in in React.

Other things I would love, fragments by default.

So if you have Oh my gosh.

If you have 2 siblings like, if you have a component that returns, like, 2 div siblings and you try to run it, React will say you cannot return 2 siblings.

And it knows what you did, but it won't fix it for you.

So I would love I love for it to just wrap it in a fragment, and a fragment will allow you to return just 2 sibling. It's a ghost element. So, like, why not if you know what the problem JS, React, why not fix it for me? Just go the extra mile and do that for me. That was a really good point when you said it knows what the problem is. Yeah. Okay. Well, why can't you account for the problem then infect it? Same with automatic keys. All the time, I I forget to put a key. I'm looping over something, and every time you loop over an element, you have to give that element a unique key so React can track where it is. And very often, I'm looping over a list of people or pizzas or something, and they all have an ID. So it would be cool if React could infer the key from the data because it's labeled common things like key ID, underscore ID, things like that.

Yeah.

And I certainly understand the importance of explicit keys, but, hey, why not have something automatic as Wes, right, where it's automatic and explicit, Wes it's explicit? I guess the concern there is might that it'd be too confusing to to have that and just have one way of doing it, but still, I don't know. I like the automatic where I can get it. You Node, I also really like the syntax that was in the and this is another Svelte thing. I I really like the syntax in Svelte. There's a template tag for awaiting promises Wes you just have a pound await and then the expression and then a colon then and then a colon catch. It's like, alright. Inside of the the the template tag is essentially the ability to accept or reject or whatever the prom not accept or reject, but output the result of the promise or output the error state without having to do the if error blah blah blah JavaScript, and you could actually throw it right there in the template. It could make things a little bit simpler than we have in React. Because right now in React, you would have to do all that before the JSX starts, right, or do some sort of a wrapper. Right? Where what makes a little bit more sense to have some of that stuff in line sometimes where you can have the outer shell of the component render first and then the interior shell of the component be conditional.

It can get a little confusing when you have that multiple wrapping elements sort of going on there. Totally agree. That would be fresh if we had that. Oh, yeah. Okay. It would be very fresh. You know what else is fresh? What else? FreshBooks.

And FreshBooks is a longtime sponsor over here at Syntax. And what what is FreshBooks? Well, they're the cloud accounting software that we know and love over here that gives you some really great features such as little helpful nudges to get people to pay the bills on time.

Say, I did this work, and, I didn't do it just for exposure here. So how about we just nudge it along here and, maybe you're a little bit overdue, send them a little reminder, and it's a little bit less aggressive aggressive than sending them an actual reminder.

So check it out at firstbookzed.comforward/syntax, and let them know that you heard about them from syntax in the d section that asks. And if you sign up today using freshbooks.comforward/ syntax, you'll get a 30 day unrestricted free trial. So do that right now.

Okay. So let's keep moving along here. Let's talk about, some more JSX stuff. We we talked about this one already, but simple scoped CSS, like scoping CSS baked into JS, be very easy.

Sorry. That's hilarious.

There just needs to be a standard way of scoping CSS in React without us having to resort to using 800 different CSS libraries.

Yeah. I feel like that is either gonna come to CSS or React soon because I feel like now that we are using CSS variables, maybe nesting is coming to CSS.

You don't even need a whole lot of nesting if you're using scope CSS. So, like, I think a lot of people are gonna be moving away from these CSS frameworks because we've have it all in in CSS or most of it at least. Totally. Next one, we have here a shorthand for props all the time. If I have a component and I've got a bunch of variables and I have, like, price and I want to pass the price variable down as a price prop. You have to say price equals curly brackets price variable.

If you have 2 or 3 of those, it gets kind of weird because you're just passing it down. So like, a shorthand for passing down a variable as the same name of the variable as a prop would be pretty cool to do that. I know that you can create an object and spread those in, but still that that spreading, I think, is confusing to a lot of people because it's got 3 dots and curly brackets and whatnot or even just putting a variable in the attribute. And it would just it would just pick that it's a variable in scope and pass it down would be really, really

nifty. It would be really nifty, and I really hate having to do prop equals prop. I just really don't like it. Svelte just lets you do it, pass it in. It seems like there there could be some sort of a shorthand to indicate this is a prop. You know? Like, what if it was just like a dollar sign bracket prop in there? I mean, obviously, that's not like a real JavaScript syntax. Emoji or something? It's just anything. Right? Yeah. Give me a ghost emoji and then whatever Wes passed along. Just anything. Right? It's just extraneous. And, again, it's just almost extraneous for the sake of being extraneous.

I guess you could say it's to keep in mind of JavaScript. Right? It's trying to make things more TypeScript. But just like that, I think there would be also like, it would be nice to be able to see use back ticks.

I I you wrote here prop interpolation without backticks, and you just had a string dollar sign first, dollar sign last JS as like a prop. And I thought that was really interesting, and I I I thought that was maybe a little too radical. So I was like, well, how about even this Oh, just just back ticks? Less radical version of just do a back tick.

Name equals back ticks dollar sign bracket first, dollar sign bracket. Then it's a little bit more like JavaScript. But right now, we have to do Yeah. You're right. Name equals bracket back to dollar sign bracket, like, comma. I like that a lot better. That's it's keeping true to to JavaScript as as is sort of

how React likes to do it. Let's move into the last section real quick here. It's just this tooling tooling around React.

So a story for easy, prettier, Babel, TypeScript.

This is this came in on Twitter because I thought, like, like, I know I know React has React scripts, and they have their own Babel config. But if you have to eject, that's kinda weird. And, apparently, there are some more issues around trying to use that in development as well as production.

So I know that that is is currently being worked on as well. One of these things I thought would be really interesting, again, I pulled this from a Svelte Sapper perspective, is that because in Sapper, obviously, it's sort of like a Next JS equivalent, everything's so baked in. You can just do to do routing, you can just do a like you would in HTML, and it automatically turns that into client side routing, which opposed to the ability to have a link from React Router having to bring that into the link tag. Link 2 is a special syntax. It's not HTML.

And then even worse with Next. Js, you have to do a link and then an anchor tag inside of there, which is just madness to me.

And sure enough, when I suggested this on Twitter, I got a lot of, why don't you just import Tolinski globally? I do that. Why don't you just have link available or reassigned to a capital a? I do that.

But those things don't really make up for just how nice it is to write an HTML aref with, like, absolutely no special syntax or nothing in there and just have it automatically client side route. It is a fantastic experience and Wes I wish I could replicate in React land.

Especially for Scott and I, Wes we're teaching this stuff, and we can't put too much magic that is not standard magic into our stuff because people are going to be going into projects where it doesn't have this exact same setup. And if you stray too far from that, people get frustrated because you taught them something that was a little bit different. So that's why it's kinda I always like to sorta keep it as close to what's in the box as as possible.

Yeah. Especially in our our content.

Yeah. Last 1 we have here is just scaffolding component generation.

I know tons of different frameworks have this sort of thing where you can scaffold out a basic file. It wouldn't be all that much for React, but, it just, like, sort of some basic setups. And and I think a lot of these things that we talked about as well JS why people love to use Next. Js because they've taken the base of React, and they've added a lot of the stuff that we're we're talking about on top of it, which is because, like, I haven't used React scripts or, like that's React scripts, right, where you eject. I haven't used that in Wes over a year. I've used create React app because I want server side rendering. I want route I want route baked in routing. I want server side rendering. I want that stuff, and and I wanna have to think about it. I'm gonna call it here. I think React is gonna announce some stuff for SSR in the next 6 months. So I think by the end of the year, React will will roll out some special SSR stuff where you can do partial hydration from the server. You don't have to ship as much stuff to the client because a lot of it's happening on the server. I bet that's what's going to happen, and I bet that's why they are dragging their feet on rolling out suspense. I think that's a pretty reasonable prediction. Yeah. That seems about right to me. I

if if you were to predict how many of these things that we suggested in this episode were to actually come true, what would you predict? What do you think what do you think our our our average rate? Do you think one of them, which would be the one that we already know JS coming, or do you think any of these things will actually come? 3 or 3 or 4 will probably make because maybe some new some new common hooks we'll see. The class and class name thing we'll see. I bet unmounting for animation.

Yeah. So animation stuff will definitely and then the rest is just you you lean on the community for that because it's just not React's job. They've they've always been like that in a long way. They've just said, no. You you choose your own package for whatever it is you wanna do. Then that's cool too. Totally. Totally.

Well, thank you so much for tuning in. Let's move into some sick picks. Do you have a sick pick for me today? I do. You know what? I've been you know me. I I get into some new podcast territory. I like some podcasts

podcasts and up. So let me, suggest a podcast here while I'm gonna sneeze.

Yeah.

My dad really makes these really elaborate sneezes, and it's decided I wasn't sneezing elaborately enough, so I decided to step it up. I'm a scream sneezer.

Wes, like, where you a ciao. Yeah. You know? And my wife recently noted that our children are all all 3 of them do it. Oh, no. They all scream sneeze. And I so I tweeted, like, like, oh, no. My my my kids have the scream sneeze.

Like, I can't sneeze quietly. Like, I feel like I'm gonna, like, blow my back out or something like that. So I it's just it's a it's a production, and my kids have done it. And somebody on Twitter said my favorite bit of trivia, Morgan c underscore Smith on Twitter says, time to break out one of my favorite facts. Making noises while sneezing is a learned response.

And we know this because deaf people, obviously, mostly don't make a noise when they sneeze, so does learn from watching you.

Yeah. Right. Yeah. That makes so much sense. There's a deeper story here because I used to not be able to I used to say I couldn't sneeze. It's not that I couldn't sneeze, but when I went to sneeze, I would tighten up and I'd hold it in, and then, like, my ears would pop or something, or I had just had the hardest time. And the only way I learned how to appropriately sneeze, was to start really going, like, goo, like, these big, big sneeze noises that my dad my dad was always like you know, my my dad would do it. My mom would roll her eyes or something because it was over the top and ridiculous.

So, yeah, that's that's my sneezing story. No. My podcast here today Wes going to be a podcast that I've been really enjoying. I don't listen to very many tech podcasts. There's a there's a few, but this one, I just I've been I've been listening to it every day, and so far, I feel like it it has made me smarter. So I'm gonna suggest it to you, which is if you're not listening to Software Engineering Daily, please do. It's very fantastic, and it's it's it's not like a fun syntax experience, so to say, but it is definitely a very educational experience. And maybe half the time, it's a little bit not in my wheelhouse, and I'll just skip those episodes. But for instance, we mentioned Mux earlier in the episode.

There's an episode on May 29, 2020, Kubernetes versus Serverless with Matt Ward. Oh. And that is an episode that really blew my mind in a lot of ways. So it was really fascinating to hear people having these big problems that I'm not necessarily having myself, how they're solving them, and maybe some of this technical stuff that can be occasionally over your head at points, but also at the same time give you a little bit of base knowledge for various aspects of even maybe server infrastructure or stuff that you've never really cared to think too much about before that you might not had to, but it does give you that nice little ability to understand the concepts a little bit better. I think the host is great. He has really good questions. They get into it, and not every episode is super relevant by interest. But for the most part, I found them all to be very good so far.

Alright. I'm going to sick pick another tool. I've been on a tool kick lately just because we're just doing a bunch of work at our place. And a while ago, I I sick picked. My sick pick was a pick quick. So there's these screwdrivers that you you can't lose the bits to because in order to get the bits out of the handle, you have to push the old one in. It's it's it's genius because you you can't ever just, like, leave a bit lying around because if you lose 1, you're screwed, and and you can't take them out without pushing the old one through. It's it's awesome. And I I said, picked it a while ago, and I have the the sick pack. The sick pack is just all the screwdrivers you would ever Node, and I also have the stubby one just thrown in our glove box if we ever yeah. It's it's a tiny little it's literally called the stubby.

That's good. They also have a Teensy Turner for for things like tech gadgets and whatnot.

Turner? Oh my god.

But the Node I'm gonna sick pick today is I called it last time, the junk drawer screwdriver.

It's just a smaller version of the 6 pack with slightly smaller bits, and it's perfect for around the house stuff. Like, it's you can still do your fill ups. You can pull a drywall screw out of it. But if you need to, like, take a battery cover off because the kids need a battery swapped out on their annoying toys, or I was working on my garage door, and I needed the a tiny little screwdriver to to clamp down on some leads. And I was like, this screwdriver is awesome because it's not like a tiny little set of jeweler's screwdrivers, but it's also not the big one. And it's the perfect junk drawer screwdriver. It's the perfect screwdriver for having around the house, and we keep it in the house. And it's awesome. The one that I have is called the Hex Key Pick Quick, which it says is for machinists and mechanics, which I don't I don't know that I guess so. But it's the perfect they should call it the junk drawer screwdriver because it's great. And I I don't know if you can can you go on Amazon and see if you can you can see these? Because it's a Canadian company. Pickwick, p I c q u I c.

The Pickwick sick pick little, screwdriver family. I'm getting them here in a variety of colors too. Which color did you go with? We're all wondering.

I think that they're colored based on what they do. What? So the the red one is what I have. That's the 6 the 6 pack, and then the junk drawer one that I'm talking about is the yellow one. No. I do I see I see the 3 multi driver family available in orange, blue, red, green, all of the same thing. Oh, okay.

Maybe I'm, yeah, maybe I'm wrong about the colors then.

Maybe you're wrong about the colors.

Yeah. Mhmm. I've I've never been so passionate about a screwdriver, but I was just using it the other day, and I was like, this thing is awesome. And my wife is like, that's the best screwdriver we've ever had.

Yeah. I bought a a screwdriver set off of Amazon for, like, phone project stuff. And, again, very passionate about that screwdriver. That whole set has been very fantastic. I I understand being passionate about a screwdriver. A good one really, really definitely comes in handy. Yeah. I just looked on on Amazon US. $12 for the one I'm talking about. Cool. Alright. Well, let's get into the shameless plugs part of the episode where we talk about things that we have created ourselves. Now I have created a course on SAPR that came out last month, and it's SAPR for Everyone. We teach you about how you can build full stack, super side rendered, or statically generated apps using Svelte and Sapper. So if a lot of the features that we mentioned in this episode, things being pnpm dreams to come to React sound kinda interesting to you, maybe you wanna check out in a fully server side rendered platform, check out the sapper course because my site's built in sapper. I'm I'm I'm a big fan. I like it a lot. I'm gonna shamelessly plug upcoming course of mine. It should be out in, I don't know, maybe a month or so. It's a a Gatsby Gatsby course. I don't have a name for it just yet, but it's going to teach you to build

websites with Gatsby, talks about sourcing data from a headless API as well as from a REST API JS well as how do you do live data in Gatsby, and you don't have to rebuild it. Like, when the page loads, how to fetch that data. So pretty happy with with how this course is going. It should be out in in, a little bit after you listen to this. So just go to westboss.comforward/ courses. The rest of my courses are there as well, and you can grab them for $10 off with the coupon code syntax.

As always, we will catch you next Monday where we're gonna be talking about what, Wes? Forms and inputs. Yes. We already recorded it.

Alright. Later. Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget to subscribe in your podcast player or drop a review if you like this show.