Check out a free preview of the full Reactivity with SolidJS course

The "Show" Lesson is part of the full, Reactivity with SolidJS course featured in this preview video. Here's what you'd learn in this lesson:

Ryan introduces SolidJS control components. While SolidJS supports ternary operators for conditionally rendering components, the Show component provides a more declarative approach. The "when" attribute contains the condition and fallback content is provided for when the condition is false.


Transcript from the "Show" Lesson

>> It's finally time to do some actual SolidJS code. We've been actually using it this whole time, but now I wanna go beyond the language of reactivity and get into the pieces where we actually need to author applications. And for that, I'm gonna focus on three areas. We're gonna focus on control flow, which we've seen a bit of already, things like the For component.

We're gonna look at a bit more at the fundamentals around component authoring. As you saw, props are a little special in Solid, so handling them is a little special as well. And then we're just gonna look at like all the DOM binding. If you're familiar with JSX, some of that will be pretty familiar but for those who aren't, I think it will serve as a good introduction.

And the way we're gonna do this is I'm gonna talk a little bit about each of these topics, show some quick examples of what those API's are. And then I'm actually gonna pull up few of the exercises form Solid JS's tutorial and do some stuff in the playground and just kind of try them out and see how they work.

First, control flow. As mentioned before, pretty much every UI framework has some kind of mechanism to describe control flow. Part of being declarative is having a syntax to describe conditionals and loops, and it's different in a lot of them. Some use HTML attributes to kind of indicate, some use things mustache templates almost.

And for us we use components, JavaScript expressions still work but the components kinda let us package up the optimizations in a nice way. So I've already kind of shown this example here, but just kinda emphasize anything again, while we support maps, we care about optimizing because of the fact that we do create real DOM nodes.

And we can compose them we write our own components, but Solid ships with a few of these we've seen For, but we ship with a few other control flow components ourselves. And they fall in kinda two categories. We have the conditional control flows and we have the loop ones.

And for the conditionals, the most basic one is show, which displays content when the condition is met. [LAUGH] Then we have switch, which is kind of a if/else, or select/case kind of control flow that lets us do kind of nested mutually exclusive options. We have dynamic, which is how we swap the specific component being rendered.

This is important because our components don't rerun again, so we can't just reassign a variable and make that a new JSX element. There has to be a special control flow for it. And then lastly, there's error boundary, which we use to catch any errors in the view and then show a different fallback.

There's actually one more that we'll address later in the workshop, which is suspense, which I also consider control flow one, but we'll get to that. On the loop side, we have two, which you might think, that's a little bit strange, why is there two, well, by default, we use the For components.

And the important thing with the For component is it's keyed. And what that means is when the DOM elements are, sorry, when the data is set to a DOM element, changing that data, rearranging that list means that the same DOM elements come with it. So if you have a list of elements and a list of data, you change the order, the order of the DOM elements change as well.

And this happens automatically because Solid uses reactivity to update which means that everything is by reference, you don't need to manually put keys in, it just works. However, sometimes it makes sense especially when you have primitive data like maybe a list of strings or something that doesn't have kinda a static reference that you don't actually have a key.

And in that case, we have index which lets you essentially key by index which is like what happens in other frameworks if you don't include the key prop. So I'm going to use this moment to go over and actually pull out the Soled JS's tutorials for a minute. We have these great interactive tutorials and we've talked about a lot of the topics already in them.

But this is also a great kinda smorgasbord, so to speak of different APIs, it's not the full API reference which we have under here, but it gives you a good idea of how to use these in applications. So I strongly recommend looking into them, but I'm gonna go through a couple of these examples, kinda give my personal take on them, which is hopefully, better than what's written.

I tried my best when I wrote the docs originally, but some of these examples will kinda illustrate essentially how these things work, right? So I'm gonna start with show because show is probably the most basic thing. And pretend you had a system where you have login and logout and you just wanna switch between login and logout, right?

And right now we're showing both buttons but it'd be nice if we could only show one and to be fair, if you want to, you can in Solid, write something like this. Use JavaScript and write a ternary operator, and then if you're logged in, show, sorry, I got it backwards, didn't I?

If you're logged in, show the logout and vice versa, right? So right now I, actually wait, no I did have it right the first time, sorry. Right now we're not logged in, we press the login button and now we get the log out button. And Solid actually can tell that these ternaries are JavaScript syntax, so we actually can optimize these.

But we also provide the show component and the show component, Essentially takes a condition, show when. Logged in. And then when we're logged in, we show this one and we've kind of got a convention for fallbacks where. We can go fallback equals this, and we get the same behavior and it's the reason why we care about having this kind of optimized show is because getting back to our infamous counter.

Picture if you had something that was show if count is bigger than five. Well, when count is smaller than five, we wouldn't really care because we wouldn't be showing anything. But if count got bigger than five and went six, seven, eight, nine, you don't want to rerun that expression over and over again.

You don't want to recreate the component every time you go five, six, seven, eight. So this is what Solid's show component does, it makes sure that it's only when it switches between the Boolean states that we actually like, the truthiness that we actually do a new render. And to be fair, our compiler automatically does this with ternaries as well, but I just wanted to kind of indicate why this is an important consideration.

Show component actually doubles up. Interestingly enough, we can add a keyed prop to it. And this lets it take a function that passes in, like in this case it doesn't matter because it's a Boolean, but if there was some kind of value, let's pretend this was user. Let's say if I get a user signal, you could actually pass in a user in here inside the JSX.

And what this would do is say, no, we actually want it to be keyed so that whenever the user changes, we actually re-render this. Because by default, show is only going to render the main thing the first time when it goes from true to false. And this is good usually because inside you'll have other things in here that say that read user and it'll still update independently like we've talked about before.

But sometimes you do wanna associate the DOM element with the data and it has this form. You might be saying, okay, well I'm just gonna use ternaries. Go ahead, for simple expressions, you can. What we found is that one of the really interesting properties with control flow components is that, The way that the layout, once you have more logic and you start getting bigger blocks of code, you're entering the JavaScript less often with the components.

So you get a more layout-focused look when you kinda layer everything out this way instead of having as many jumping in and out of JavaScript. It's an interesting observation, you'll have to test the mileage for yourself but this is kind of part of the thinking behind this. And that's basically the show component.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now