Preact: Into the Void(0)

(synthesiser intro) - Everybody, so, is everybody here actively caffeinated, 'cause this is gonna be a little bit thick, but in a fun way, I assure you.

And also, I have a laser pointer, just in case, which I just found out, which is pretty awesome. All right, by the way, that is not loading anything. I just put that in there to scare the techs, 'cause I find that hilarious. (audience laughs)

Also, it's just a really cool spinner.

I think it's from Gerbil. I have no idea where it's from. Okay, so like John said, my name is Jason Miller. I'm from the woods in Canada, which for those of you who haven't been to Canada is about an hour west of Toronto. I am developit on Twitter, no, I'm developit on GitHub and _developit on Twitter. I'm pretty sure the person who has the non-underscored version is Australian, so if you're here, we should totally talk.

(laughing) I have no ulterior motive. Okay, but so more importantly, I'm a serial library author, and that's self-diagnosed. They're still working on figuring out what the definition for that would be.

What that means us I'm fairly obsessed with this idea of constraints.

I started building stuff for the mobile web around the time the mobile web became something that you and I would all use, so, you know, the introduction of iOS and then subsequently Android, and even a little bit before then.

So Windows Mobile, the whole Palm Pre story. Never forget. (laughing)

I've created a bunch of UI frameworks kind of along the way to the point where it's actually become a fairly serious problem for me, because I have to go around and clean up after myself and delete all traces of these things from the internet such that I can't be held accountable for my past mistakes. So, the reason why I like constraints is I find constraints to be very interesting challenges. This is incredibly relevant for me because I have something called Attention Deficit Hyperactivity Disorder and I can't say that any faster than that.

Basically, this means that in order for me to be able to focus on something to the best of my ability, I need something I can really sink my teeth into. I need something that I can essentially like, dive into, lock myself in a tiny box for six days, and then, you know, come out of it with some sort of an interesting solution to a problem. I especially like challenges where the assumption is that something is impossible.

Oftentimes, it turns out that it is, but it's fun. (audience laughs) It's fun to investigate, especially in a browser context. No offence to the browser. Okay.

So, over the last couple of years, I've been particularly interested in one challenge, one constraint, which is file size, or you may see this referred to as bundle size. I like to think of bundle size of file size as a fairly quick essential optimization problem. We want to kind of maximise the productivity that we get out of the libraries that we use and the code that we write, but we also want to minimise the size of the code that we deliver to our users.

A way I like to describe this is we wanna stand on the shoulders of giants, but then compile those shoulders out. (laughing) Apologies to all giants. So I'm here today to talk to you guys about Preact. Preact, like John said, is a tiny little library that has a similar API to React.

Sometimes I say same API; sometimes I say similar API. It depends on the day of the week.

Also a very difficult thing to track.

So, how many people here have heard of Preact? I know this is super self-aggrandize...

Oh, that's way more than I would have expected. I was thinking like six people, all front row. My wife. (laughing)

Yeah! Hi, mom. (laughing)

Okay, so I'm actually going to explain today more about how Preact works than how Preact is implemented or why you should use Preact, more about the kind of design decisions that go into Preact to help it stay small and focused and fast. If you're new to Preact, you're probably wondering what on earth does this look like.

I usually wear it as a shirt, but here it is as a slide. This is the entire library with some weird white space stuff on the right.

Line wrapping in a browser. Who knows.

But this is the whole thing.

I've spent two years working on this.

Sometimes I cry. (laughing)

I always tell people that aliens are going to come to earth, and they're just going to see me screaming at this, and they won't need to understand my pain.

They'll just feel it.

So we're actually going to spend 45 minutes talking about this slide.

How exciting is that? In particular, we're going to talk about that, laser pointer, but that is really important once we figure out what this is.

But neither of those two things will make any sense until we've covered the yellow bit there.

Because it's a Preact presentation, we have to have some purple.

I have no idea what that's highlighting.

I never actually thought to check.

For those of you who are worried, I do have actual slides here.

There are real slides in addition to this code slide. The thing is, we can't talk about any of these fantastic things that have been highlighted here until we've talked about the elephant in the room, which is JSX.

You saw Zero's presentation.

JSX is probably not a thing that people are afraid of anymore, but it's still something that people maybe don't understand as well as they could, and don't feel bad if that's you.

There's no reason to feel bad there.

JSX is really simple, but it's the kind of thing where you don't have to understand it to use it. I'm going to try and break that down.

We're going to learn JSX in the next like, five minutes. My goal by the end of this talk is to have everyone here rewriting their webpack configurations in JSX by the end of the talk and then writing them back not using JSX having realised that is a terrible idea. (laughing) However, it is a documented terrible idea.

This is the webpack documentation on how to write your documentation or your configuration in JSX. You can also see there's a Preact cameo in there, which is kind of hilarious.

And actually interestingly, you know, all that stuff there is implemented in Preact. Like the actual rendering, even the sidebar on the webpack documentation is implemented in Preact. Most of the page even at this point is.

So it's like this weird of full-circle thing that now I get to put into a presentation, which is fun. So what is JSX? JSX is an XML-like expression that is compiled to a function call.

That slide should update momentarily. Yeah. So, and this is like my Merriam-Webster definition slide, I had to have one in here. So, it's, you know, we wanna write the thing on the left and we want to see the thing on the right.

So we wanna write one, compile it, and then get the other one.

To me, the value of JSX has always been that if you had to write the thing on the right, you'd still keep your job.

You wouldn't quit. You'd be okay.

It might not have as many as angle brackets, but it's pretty serviceable.

I've actually written whole apps like that. There's lot of people who do. I'll show you that in a bit.

But that's really it.

That's like, kind of, the basis of JSX, is a little compiling of angle brackets.

Other than that, there's really only two things that we care about.

The first is you can always jump back into regular old JavaScript land, the JavaScript of today, and you can do that using these curly braces. So you can see in the example on the left, we've got curly braces around that one literal and curly braces around the reference to the world variable. And they just kind of come through verbatim of the right, so they're not affected by the JSX compilation. Similarly, if you use an uppercase character as the first character in a tag name in JSX or a nodeName, it's going to come through as a variable reference instead of a string in the resulting, you know, compiled code.

This becomes really important, because that's how we leave function references in JSX, and that's how components work.

So we have our XML expressions and we have our references coming through after. So, what is h? What is this h function that has been randomly inserted in the place of all of our tags? That's actually up to us to decide.

So we get to define what that is.

We get to define A, it's name, but B, what it does. You'll often see h referred to as createElement or react.createElement.

That's just the Babel default.

That's just literally the name of any function to call, it doesn't really matter. We get to define what that behaviour is at runtime. All we have to do is define a function that adheres to this signature.

So, it need to accept nodeName, which is gonna be like div or that variable reference. Not gonna be a string or a function.

It needs to accept attributes or null if there aren't any. And that's gonna be like id equals food, for example. The rest of the things that were contained inside of this JSX tag when we wrote it, those will come through as the rest of the arguments, which we're gonna call children.

So you might be sitting here saying, "Yeah, Jason, I existed during the year 2000, "so I know that this is something "that might have been called HyperScript at some point." And, you know, props to you, that's a cool reference. It's one that I only got like later on.

So super props there.

And by and large, that wouldn't be entirely incorrect. So I've literally copied and pasted this text box, so I know it's exactly the same, but you can see the left and the right are very similar, nay, the same.

So in that regard, it's the same.

You can transpile JSX to this h function, or you can write Hyperscript, and you'll get the same result.

Where they're not quite the same though, is Hyperscript had this extension where the tag name can be kind of this CSS selector shorthand and it will expand those into attributes on the element that it creates. Hyperscript creates DOM elements.

And then in the JSX world, this isn't something that Hyperscript doesn't do, but it's just not commonplace there. We can leave a variable reference as a tag name. So it might be a function, might be a string, who knows, and then we often use non-string or even non-scalar values for prop values.

Doable in Hyperscript, but not common.

So, not quite the same there, but interestingly, JSX's compile target is what you would consider to be a subset of HyperScript, which ends up being important.

So it's worth having a really solid understanding of this, because the JSX concept is not only simple, it's also very direct.

We can take a look at the Babel REPL, and I would encourage you to do this if you're just kind of getting into JSX or haven't heard of it before, and we can, you know, we can write some angle brackets on the left, and we can compile them to some h function calls on the right. And it's pretty easy to get to the point, after a few minutes with this, where you can see JSX and imagine exactly what the Hyperscript corollary would be and exactly the same thing the other way around. So you can see one and imagine the other.

Also, I wanted to stress, there's nothing about JSX that says it has to produce DOM.

They're not inherently related in any way.

You can define a JSX function that returns XML strings, objects, more function calls.

I have no idea why you'd wanna do that, but you could do it, the possibilities are endless. So, one example of this would be the webpack config that I showed, that crazy idea.

That is a JSX h function that creates objects. Another more concrete and awesome example would be, I'm working with a SOAP API right now, and I know everybody cringes when they hear SOAP. I actually really like SOAP. I think it's pretty cool.

It's like a precursor to GraphQL.

But SOAP can get kind of gnarly on the client, because you send up serialising and deserializing a lot of XML, and XML white space, and encoding, and all this kind of business.

JSX makes it super, super easy because JSX is a way to write XML in your JavaScript, and then if you just define an h function that serialises stuff to a string for you and takes care of all the encoding, and all of the sudden, working with SOAP in JavaScript kind of feels native.

It feels like E4X, which died.

Okay. So, yeah. (laughing)

But it feels better than that.

Okay, so that's JSX out of the way.

The next bit sort of on our journey is Virtual DOM. Again, like JSX, it is a simple primitive, but it is a useful primitive to understand fully. So, what's Virtual DOM? Virtual DOM is just nested objects that define a DOM tree structure.

That's it. There's no behaviour.

There's no fancy stuff, no special sauce.

It's just nested objects.

I actually like to think of Virtual DOM as a big configuration object that we would pass to a theoretical DOM builder function, and it would return a DOM that matches that big configuration object.

So it's just kind of a simple creation process. So, how do we get from JSX to Virtual DOM? We know that we can get from JSX to HyperScript by transforming it uses a compiler like Babel or Buble. Yeah, whatever. There's lots.

I'm curious what the next one's gonna be called. I feel like we've run out of B names, but who knows. So we know we can get from one to the other. How do we get to Virtual DOM? Well, as it turns out all we need to do is define an h function that when invoked returns Virtual DOM objects.

That way, we can get all the way from JSX to VDOM objects. So, to clarify, what we wanna do is we wanna write the angle brackets.

We wanna transpile that to these h function calls, and then when invoked, we want that h function to return objects that looks like this, that have this sort of DOM-like structure.

So, what's that function? What is this h, this concrete h function that we need to write that does this job? I'm happy to say this is my favourite kind of function, which is a useless one-liner.

I write them all the time. They're kind of my standby.

All this does is it takes the arguments that we pass it, you know, makes children into an array, but that's giving it too much credit, and it returns them as three properties on a plain JavaScript object.

You'll sometimes see this object referred to as a vnode. This one doesn't inherit.

It isn't a constructor or anything like that. But it counts as a vnode, just because of its structure or Virtual DOM element, sometimes you'll hear. Same sort of deal.

In reality, we probably want to do some normalisation in this function.

You might wanna strip out any empty entries in the children array, or if there's infinitely nested arrays inside of children, flatten them down to just their internal values. But that's just to make our own lives easier. In reality, you could build a Virtual DOM library using this, so let's do that.

The whole point of Virtual DOM is we wanna realise these objects into real DOM elements so that we're not just working with something that is a data format.

Data formats are cool, but you're not going to build a user interface with them.

So, rendering is fairly straightforward, kind of like the JSX, kind of like the Virtual DOM. All we have to do is we take our object that we passed ourselves up there with the scroll bar, and we invoke the DOM method to create an element with that given name.

So we have a nodeName of div.

We call ddocument.createElement(div), we get back a div, and we assign that to node. Second thing we do is we loop over the attributes object, which in this case, has one property, id, with a value of foo.

And we call setAttribute(id, foo). Simple.

You can see we're kind of creating that DOM builder function that I said was theoretical.

Theoretical no longer.

Then what we do is we loop over the children property, which is an array.

You see that there on the right.

For each child in the children array, we invoke render again.

So we're setting up recursion here.

We pass it the virtual child, which is hello or the nodeName, be our object there, and that we're gonna get back a DOM node.

And that DOM node, we can just append into the current DOM node.

So we set up recursion, and then using recursion, we set up a hierarchy.

There's one extra little tidbit here that we have to write. You notice the first entry in children, the first child there, is just a string? Technically a string is a valid vnode, and what that means is we have to special case it. So what we do is we just check if the vnode's type is string.

If it is, we bail out with the DOM text node. Simple as that.

I did gloss over one thing here that's fairly important. I've been calling these things attributes, and anybody who writes React is probably like making that crazy screaming sound in their head that happens. I think that's a Silence of the Lambs thing. I don't know. I've never even seen that movie. So I've been calling these attributes.

That's technically incorrect.

More often than not, we want the latter, which is properties.

We might express them as attributes in our JSX, but in reality, we wanna set them as properties, 'cause it's a little faster, a little cheaper, a little more direct.

It's certainly, from a JavaScript context, it's more the API we tend to work with.

The thing is, both of these are at least somewhat incorrect. The problem is there's attributes that you can't set as properties, and there's properties that you can't set as attributes. You can't set non-string values as attribute values. So we need both and the best way to do that that I've found kind of two years on is through an in check. Essentially, if you're unfamiliar with the in operator, it just checks to see whether a given property exists on an object, including searching to the prototype. This is super useful for us, because let's take our example where we had an attributes object with an id property whose value was foo.

We're gonna come through here, we're gonna hit the in check, and we're going to be saying if id in node, which we know is going to be true, because nodes have an id property.

It's null by default.

Then we're going to set it as a property.

So we're essentially asking the DOM, do you support this property, rather than trying to have built-in behaviour. Preact is three kilobytes, so it can't really have its own behaviour.

There's no room for that. It can't have white lists.

It can't have mappings or any of this kind of fancy stuff. It just has to ask the DOM for everything.

And so in another case, let's say we had a data attribute, data-foo, it would fail the in check and we would just fall back to setAttribute. So it actually ends up working out quite nicely. Interestingly, with the advent of custom elements and web components, web components have this state they're in before they get initialised.

I think it's called uninitialized state.

And there's no definition there for the component. It's just kind of a dumb element.

In this case, the in check will fail for any custom properties it's added, because they don't exist yet. And so we set them as attributes.

This is really useful, because when the custom element comes and initialises, it can loop over the attributes that have been set on it and initialise with the correct data.

We just have to serialise it.

Once initialised, though, custom elements often define getter/setter pairs for the properties they support on the elements that they've decorated.

Now the in check passes, so now we can start setting complex types on these elements.

This has really interesting implications.

Honestly, it's still kind of in flux.

There's lots of people looking into the implications of this, but I think that this is kind of a key, a key insight.

So that's that. We wrote a bunch of code just now. We wrote a render function. We wrote a JSX reviver.

We gotta test this stuff at least a bit. So, here's a test. We're gonna define a Virtual DOM tree, and at this point, once we've assigned the variable here, we're just gonna have nested objects, not actual DOM elements.

We're going to have a title tag represented in JSX and a list represented in Virtual DOM.

We can pass that to a render function to realise or actualize that tree.

We get back an actual DOM element that has the recursion and the nesting, and then we can just pass that into body. So, does it work? Yes.

Also, the network works, which is good.

I'm always like, is it gonna white screen? No. Okay, good. So, yes, it works.

Let's get that out to production.

Obviously it's pretty important.

We've gotta get this list out there.

People want the list. Okay. I have a lot of list apps.

It's my thing. Okay.

So we just build a simple Virtual DOM renderer. The problem is we built a horrifyingly bad Virtual DOM renderer.

It's terrible.

Any time data changes, we're going to want to update our user interface, and the only way for us to do that is to tear everything down and rebuild it from scratch. That's going to take a very long time, especially using the Imperative DOM APIs.

At that point, it probably would have been easier for us to just use inner HTML, and arguably, better. So let's not do that. Instead, we need to use diffing. So the diff algorithms used by Virtual DOM frameworks are subject to a fair bit of debate and mystery. I think some of that is warranted, because this is complex stuff, but it's also unfortunate, because in order to really understand this technology as a substrate, right, if you're building an application on top of React of Preact or whatever, you know, you should really understand the fundamentals of how that thing is working so you can make sure you're using it correctly, so you're avoiding foot guns or pitfalls, whatever term you wanna use. You need to really know what it's doing underneath the hood, at least at a high level. So the fundamental premise of Virtual DOM is, what if, instead of rendering from the top down, creating each element anew as we went down, as we descended through that tree, we gave ourselves a reference to the DOM now, to the way the DOM looks now, and as we descended down through, we tried to reuse those things.

So we try and morph the DOM into the DOM we want rather than blowing it away and recreating it. So that's kind of the premise of Virtual DOM. Here are the APIs that we're working with.

On the left is a Virtual DOM. We just built that. That's our stuff, easy to understand.

On the right is the actual DOM APIs we're gonna be hitting. And you can see there's a lot of strong relationships here. nodeName, pretty much the same.

Attributes.

Okay, we've got a getItem, a setItem, but by and large, it's just, you know, map. Not super interesting on its own.

It's also iterable on both sides.

Children, the name changes.

There is actual a DOM children property.

It just doesn't include text nodes, so it's not super useful for us.

But aside from that, they're pretty much the same. It's just gonna be a list of things.

So hopefully, you can look at this and see how we would compare the left to the right and flush out the changes on the right.

So, the process for doing that is three steps. First step is we need to diff the type.

So in order to get kind of a root in the DOM, we need to create an element, and the element types are immutable.

So we have to initialise the element with a type. We can never change it after that.

So we have to do that first.

The second thing is we need to diff the children. So we've gotta compare the children in the Virtual DOM tree and the real DOM tree, figure out what the differences are, and then flush those out. And the third one is attributes, more accurately referred to as props.

We just compare with the two.

That's just a bidirectional object comparison, not super difficult.

And then importantly, for each of the children, when we're doing that comparison, we're going to invoke the diff again.

So we're going to recurse down through the diff using recursion.

If you're, you know, if you're an astute learner, I'm not, but if you're an astute learner, you realise that I've kind of swapped things here. In the previous example, we diffed props and when we diffed children.

As it turns out, that's not really the right way to do things in the DOM.

There are a couple of cases in the DOM where the children of an element define the behaviour of its properties. One that I like to use for this is the select dropdown, the select element.

If you have a select element with no children and you set its value, it's going to try to go and look up the display text that it needs to render, but it doesn't have any children, so there's no display text for it to look up. It's gonna try and search for option, children. There's nothing there and you'll just get a blank select dropdown.

Even if you then go and add children, still blank. If you flip that on its head, though, and you render the children into the select dropdown and then set its value property or attribute, it'll look up the display text and show appropriately. There's a couple of cases where that's true. There are no cases where the opposite is true. So we just flip the two.

I never went back and corrected the first one, 'cause it gives me the opportunity to talk about it. So step one here, we need a diff type.

So, okay, it's immutable, so we have to do it first. And there's kind of two sides to this story. The first side is the easier one, so I like to talk about it first.

We're gonna check that the node's a component, and this is just, there'll be a property on the element that indicates yes, I'm a component, or in the case of Virtual DOM, if the nodeName property that we gave ourselves is a reference to a function, that's a component. Otherwise, it's a string, so it's just an element. In the case where it's an element on both sides of the fence, we have our lives kind of easy. All we do is we check if the type in the Virtual DOM element is the same as the type in the real DOM element. So, is it a div and a div? If it is, we have no work to do.

We're going to update this element in place so it's a no-op. If the type is different, though, we have to essentially blow away the existing DOM element and recreate a new one, because we can't change the type of a DOM element. It's set in stone once you create it.

So in that case, we just use replaceChild and blow it out and replace it.

On the other side of the tree, slightly more complex, but I'm going to kind of try and simplify it to get us through here. I'll still kind of root it in reality.

So, if the node is owned by a component, and let's pretend that that's signalled by the fact that there is an _component property on the node, to steal how Preact works, all we're gonna do is we're gonna either create an instanceof that constructor reference, _component or the nodeName, or we're going to update one if there already was one, and that's just, you know, there'll be an instance property hanging off of the DOM element that points to, you know, the old constructor value. We just reuse that.

So, either way, we're going to get an instanceof that constructor.

In both cases, all we do is we call render on that component.

Thankfully, render just returns more Virtual DOM. We go from our component reference, which is abstract Virtual DOM.

We call render, we get back concrete Virtual DOM. This is really easy, all we do is we take the results of render, which is a vnode.

We know how to deal with vnodes. We pass it back to diff. All of this kind of occurs within the context of a single DOM element.

It's kind of a summery of one of the key features of this react component model. You can have multiple components that are owned by a single DOM element or that are associated with one single DOM element. So you can compose within the confines of one DOM element. You don't have to have six elements stacked in order to have six components stacked.

That's something that's highly valuale.

This is how high order components work and react. I feel like this is a decent way to illustrate it. It's that diff process, recusing within the context of one node.

Okay, so that's type.

Now we've gotta nail it with the right type. Second step is diff and children.

This one's pretty straight forward.

It's a little but more bidirectional.

All we have to do is we loop over each child in the DOM, so we're looping over child nodes.

For each, we're gonna put it into a bucket. If here's a keyed property on the child, we're going to put it into an unkeyed bucket. This is just an ordered list. Chuck it on, it's an array.

If here is a keyed property, we're gonna put it into the keyed map.

This is essentially a JavaScript object where the keys are whatever the value of the key property was on that element.

The values are the elements themselves.

It's pretty straight forward, we'll end up with this kind of ordered list of unkeyed and a map of keyed. Those are our two buckets.

The next thing we have to do is we iterate over all of our virtual children, that children array that we had as a property of our vnode. We have to find a match in one of those buckets, so if the vnode has no key we're gonna go to our unkeyed ordered list and we're gonna find the first instance of an element with that type in the list.

So our vnode has a nodeName of div, we're gonna find the first div in the list. We're gonna come back form the operation with either a div or no match and that's fine. Save the old for if it has a key, we're going to find the corresponding value in the map for that key.

There might not be a match and that's okay. We're gonna take whatever we got from that operation and pass it into the function we just wrote, that diff function for type. What that's gonna do is take the element we passed it, or null if we didn't find a match, and the vnode that we pass it and either destroy and recreate the element 'cause the type was wrong, create a new element because there was no element there, or just return the element we gave it because it was a dead match.

That works nice and easy.

We're gonna come out of that operation with the right element instead of nothing or the wrong element or possibly the right element. Now we know it's the right element.

Now we have to do with that is insert it at the corerect index in the DOM, which happens to be the index that we're at in this loop over virtual children. So we'd use insert before to insert that in the DOM. Third step is the easiest and my favourite. If there's anything left in the lists, we just drop them on the floor.

That means that they're no longer used in the render so we just get rid of them, empty them out. I kind of glazed over keys there and it's something I want to touch on because keys are really, really important and they are often very poorly understood.

Basically the job of keys is to attribute meaningful order to an otherwise uniformed set of elements.

What I mean by this is if you have five divs in a Virtual DOM renderer, and then you render seven divs as a second render for that same component, there's nothing in Virtual DOM that tells it, "Oh, I added two in the middle." Or at the beginning or wherever.

It's just always gonna add and remove at the end. It's dumb, it starts at the beginning and it goes to the end, so if the length of the list is different it's gonna add or remove at the end. Keys let us kind of turn this on its head.

It's easiest to see this as an example, so here's the example.

Let's say we have a component and in the first render we have three elements.

One, two, and three. These are list items.

In the second render for the same component, we have two list items.

You and I can look at this and see clearly the second item has been removed, right? There's no