1000 Ways to Autocomplete

It's time to get started. Let's get started. All right, everyone. Welcome in, welcome in, and like we said, welcome to 1,000 ways to auto-complete. So you have probably seen a UI like this before where you're going to see a lot of JavaScript. This is a lot of JavaScript. There's a lot of questions listed out below it, and you might have implemented a UI like this yourself, and in this talk, we're actually going to show how this can be implemented in a lot of different ways.

So, and all those things you might consider are things like de-bouncing input. So as the user's typing, you don't want to fire off an API request for every single key press. You want to fire off a request for every single key press. And if something's happening behind the scenes, we want to give some indication to the user. Also, we want to abort in-flight requests. So if we send off a request and then we need to send off a new request, we need to cancel that previous request, otherwise the UI could actually get out of sync. And we also need to care about error states. Nobody likes it when the screen just turns blank and white, so we should actually handle that as well.

So this is a great way to implement a front-end framework. So I'm going to show you a great example of this front-end interview question where she implemented autocomplete with React and kind of just talked about how it's a really good interview question. I've actually been asked a similar question in an interview, and it's a really great way to kind of just practice working with a front-end framework and also practice with React. So after I watched this video, I implemented it myself with React, but it really got me thinking, because in a way, it's kind of a good way to evaluate all these frameworks and all of these things. So I'm going to talk about how we're doing with conditional UIs and list rendering and state updates and effects and dependent state updates and ASync state management and all of these things that really showcase how all of these things are done across all these frameworks and libraries. So in this talk, I'm going to show you how I did it in Vanilla Js and React and Vue and Angular, preact, Svelte, solid and in HTMX.

So hello there, my name is CJ, like was said, I'm currently a web developer, I've been working with Vue and Angular, and I'm working with Vue and Angular, and I'm working with Vue. Who here listens to the Syntax podcast? Yes, yes. Hopefully we'll see more hands later. And every single episode of the Syntax podcast is brought to you by Sentry, as well as every video, so I actually make videos for the Syntax YouTube channel, and Sentry is an error monitoring platform. You can add it to your app running in production, and any errors that happen get sent back to the dashboard, and then you can get back to the dashboard, and then you can get back to the dashboard, and then you can get back to the dashboard. So you can get back to the dashboard at sentry.io. That was me. Let's learn who all of you are. Who here writes vanilla JavaScript on a daily basis? Let's see a hand.

Probably most of you. Maybe not exclusively Vanilla Js, but I think a lot of us do. Who here writes React on a daily basis? This is like 80, 90% of the crowd. That's awesome. Who here writes Vue? Yes! Okay. Like three or four hands. Awesome. Okay. So, what about Angular? Any Angular people? One. Anybody else? Okay. Two? Okay. Sweet. Um, anybody write Preact? Yeah, okay. What about Svelte? No hands for Svelte? Okay, okay. I see you. It's hard to see. There's the bright lights. What about solid? Anybody write solid? Okay. We are a React community. We have a lot to learn. Honestly this talk is really for React developers to see all the ways that things are done across all these frameworks.

Let's also set some expectations because for all of these examples I'm going to show you I'm always using the latest and current version of every single framework. Because there's a lot of ways to do things in every single one of these. I picked the latest version and then I did my best to show the preferred way of doing it by looking at the docs by reading like community guides except for Angular, which I am eternally sorry for. If you write Angular, come see me afterward. I have shiny Angular stickers for you. I did my best. But there are some areas where I will point out where we probably could have used RxJS or something like that. But I didn't have the time.

But I didn't have the time. I had to do all the other things. And all these examples are really going to focus on the code. How do we actually do this stuff? The how it works. How do these frameworks do rendering? Is it compiled? Is there a virtual DOM? That's for a different talk. This is all about the code. What do we write as developers to get this stuff done.

And also I will show these examples in isolation. You have to use your imagination to combine everything that I showed you in order to kind of demonstrate all these aspects. All right. And last warning, here be code. There's going to be a ton of code. But I encourage you, if you start to get overwhelmed, try to be on the lookout for your favorite framework like React. Or maybe as you start to see your favorite framework pop up, be waiting for it to see it pop up. Because like I said, you're going to see a lot of code.

All right. Let's get into it. We're going to talk about first how we're doing form input state. When you're building out this UI, we want to keep track of what the user is typing into this input box here. And we typically store that on state. So we can use that later on when we're making that API request. Now, inside of vanilla JS, we can grab the element from the DOM with query selector. Imagine we have some HTML. And there's an element on the page with ID search. We can grab it. And then we can add an event listener for input. So any time there is a key press inside of there, this callback is going to get called and we can use that value. So in vanilla JS, the state is actually like inside the DOM. Technically, you could pull it out. There's a lot of ways to implement this.

But in this case, every time that runs input.value, it's going to have the latest value. So state is kind of stored inside of the DOM.

Inside of React, we have our use state hook. We pass in that initial value as an empty string. And this gives us back the current value of search. And then a function that we can call to update it. So any time set search is called, that sets the latest value, re-renders, search will have the latest value.

Now, Preact is actually like a slimmed down API compatible version of React. Like this code you're seeing right there will actually work directly inside of Preact. But Preact actually introduced signals. So all of the examples I'm going to show today with Preact will be with signals. They have this hook called use signal where you can pass in the initial value and then use the same hook to update it. So the first example I'm going to show you is a use signal where you can pass in the initial value and then you get back that signal. And this is an object that has a dot value property that's going to always have the latest value on top of it. And then we can change that or override it to update it to a newer value.

In solid, we also have signals. But it's kind of like a combination of Preact and React. So we have this create signal. Pass in the initial value. This is going to give us back a getter and a setter. That's one of the main differences here. This search is a function that we need to invoke in our render to get the latest value. But that's a signal to the compiler that that one spot that called that getter actually needs to be updated whenever the value changes. And then set search, very similar, we call it to update the state.

Now inside of view, we have this composition function called ref. Now if you're familiar with React, you might think, oh, that's like use ref. It technically can be used for that. But we always use this for declaring reactive values. This is basically declaring a value. So if we want to declare a value, we can use this function.

And then if we want to access it in our JavaScript codes, we can use search.value. So it kind of looks like a signal. And the way you use it is like a signal. But that existed before the term signal got super popular in the current landscape of things.

And inside of Svelte, here in this Svelte 5 example, we're using the dollar sign state room. And so on the service, this looks like all these others. All the others. But this is actually a compiler directive. It's actually an indicator to the compiler to say, hey, search is a variable that we need to keep track of. If it ever changes, update the view. So it's not actually a function call. But it kind of just looks like it.

And then in Angular, there's a bunch of code missing here. Because we've got all these imports and decorators. But ultimately we're going to be using the form control, which was introduced in Angular 18. And your Angular components are actually a class. In this case, we'll have a search property, set it equal to an instance of form control. So that's how we define the state. Now how do we actually update the state? Oh, sorry. HTML is just an input. Because it's HTML and the state is stored in the DOM. Nothing too crazy there. But now how do we actually update that state?

Inside of React, we need to pass a callback to the on change method there. So when this input value changes, this function gets called. We call our setter, update the value. And then we can actually set the value attribute to be the latest value of search there. But this is like a little white lie. Because under the hood it actually is the on input value. So if we say on input, we'll get the on input event. But they just let us use the on change event.

And inside of Preact, you actually do use the on input event. So this is very similar. But like I mentioned, that signal, we can just directly overwrite. So we don't have to do anything special. We don't have to call a setter. We can just set the signal's value to be the latest value. And then to pass the value as the prop there, we just pass in search.value.

Now, solid, again, it's kind of like a combination of React and Preact. So we do have to use that on input. And then we have to call our setter to actually update the value. But you'll notice we need to invoke search. So that's our getter. But that invocation is an indicator to the solid compiler that this is a spot that actually needs to be updated if search ever changes.

Now, Vue actually has a built-in directive. It's called V model. So we pass a state variable down to it. And if that ever changes, this input will actually be changed. And then we can actually update that behind the scenes. Now, V dash model is just syntactic sugar. Under the hood, it's adding a change listener. It's binding the value. But it's nice that this is built in. And technically, you could do it manually if you want to. But we do it so often, they give us a nice little directive for it.

And in Svelte, there's also a way to bind to the value. So we can use the bind colon, specify any attribute, and then put a dollar sign state variable accessor inside of there. And then we can do it in the form control. But, again, this is really just syntactic sugar. It's still adding a change listener. It's still updating the value there.

Inside of Angular, now that we're using this form control thing, we can do bracket form control and specify the latest value inside of there. And in HTML, it's still just the input because the state is stored in the DOM. All right. We can kind of, looking at all these examples, we can categorize them in different ways. Manual state, I'm calling react, svelte, and then all the others have some magic sprinkled in. We have custom directives, custom things we can use. There's a little bit of magic. And then the other way you can look at these examples is some of them are categorized as immutable, some of them are mutable. In both React and solid, we basically overwrite the latest state value on every time we want to change it. But for all of the other examples, we can actually just directly mutate the state.

All right. I am running a little bit low on time, so we're actually going to skip the conditional render and then just jump right back into async and effects. But if you want to see this, definitely come see me after, and we'll talk about it.

Okay. So we're keeping track of state, we're updating it. When the state changes, let's actually say we want to call an API to get that data based on what the current state value is. For this, we're going to use the state. Now, in vanilla JavaScript, we can literally just call our API inside of our event listener there. And so imagine git results is a function that has fetch inside of it. It does the hard work of calling the API and getting back the results. But because this callback is going to get called, every time the input value changes, git results is going to call the API on every single change there.

Inside of React, we use the user. And so we're going to use the user. And we're going to call the API. And so we're going to call the API. And so inside of React, we're going to do the use effect hook. And you'll notice here, we're passing that array as the last argument, and that is our array of dependencies. So any time that search value changes, this use effect is going to rerun. And so essentially, if we're updating that search value on the input, anytime it changes, this code will rerun, it will call off to the API. All of the other frameworks are very similar. Any time we're accessing signal.value, it's able to keep track of that, and know that it needs to recall this if it changes. Similar inside of Solid, they have create effect, and this will just get rerun any time its dependencies change. And again, you're seeing that invocation right there. So we're calling, we're invoking the getter, which is a signal to say, hey, if this changes, that code needs to rerun. Inside of Svelte, they introduced the dollar sign effect rune here in Svelte 5, and we can do a similar thing, so any time it changes, just call off to the API. View has a watch effect function built in, very similar, any time search.value changes, it's going to rerun this function. Angular, it's a little bit different, and this is where I start to apologize for the example. So in this case, we are subscribing to changes of search, which was that form control property, and then if it ever changes, we're calling off to our API. This is a spot where you potentially would use something like RxJS. There's other ways to do it.

This is what you get for now, and also that ng on init is kind of like our component did mount. When the component mounts, that code will run to set up that subscription. And then in htmx, we can add this attribute hx-get. So any time the input changes, that's going to fire off a request to slash search. So I'm categorizing these in two ways. You have manual tracking, which is React, and then everything else is automatic tracking. So in React, you have to specify the dependency array. A lot of times we have ESLint rules that will remind us if we forgot a dependency or something like that, but all of the others, because they're signal-based, can automatically recall our effects and we don't have to manually specify that dependency array.

Now let's talk about debouncing. So in this example, as the user's typing, we're just firing off a request on every single key press, and this is what we want to avoid, because it's basically just pounding our API, and it can really slow things down. What we want is we want to wait for the user to finish typing, and then call the API. So the user types, and then once they're done for 200 milliseconds, then we call the API. This is debouncing.

The way we implement it is just with a set timeout. So I'll show you the vanilla JS example first, where essentially we have a timeout ID, and it starts off as empty, but then any time the input changes, we clear the current timeout ID. And so clear timeout is built into the web browser, and we're also going to use the timeout ID to actually set a timeout for the user. So basically, we start off by clearing this timeout, and then it's okay if you actually pass in undefined. It's not going to error out. But then we set a timeout. So we say, okay, in 200 milliseconds, we will then call the API. But if the input callback gets called again, we're going to clear the previous one. So basically, as the user types, we set a timeout, and then immediately clear it, because they typed another character. So set it, clear it, set it, clear it, and then finally, if they don't type, we clear it. We're renting this very thing, but in combination with our use effect.

So for React, the way that we can clear it out is by returning a function from our use effect. And so this is known as our cleanup function, right? We set the timeout stored inside of that timeout ID, but if the search term ever changes, we need to clear that timeout, and so the function that we return from the use effect is going to get invoked, clear the timeout, and basically, it will clear it, clear it, clear it, until the user's done typing, and then make that request off to get results. All of the other frameworks, very similar. So in Preact, we can return a callback from our use signal effect. In Svelte, we can also return a callback from our dollar sign effect. The one thing to note here, though, is that Svelte 5 doesn't automatically track dependency access inside of nested callbacks.

So the hack here is to just get rid of that and then just access it, and basically, like a no-op, just, hey, I need search, and then the Svelte compiler will know that it needs to rerun this function any time search changes, and again, we're returning that cleanup function. Of course, this is a hack. There's probably better ways to do it, but yeah, and then in solid, very similar, but they have this on cleanup function that you just import from the solid library. So there's no need to return a callback, and what's nice about that is you can actually call it anywhere. So if your cleanup function for whatever reason needs to be nested in a callback or something like that, you can get it done with that on cleanup. Inside of Angular, this is kind of, again, I apologize, but this is the kind of like the vanilla example combined with our subscription. So if the timeout changes, we clear it and then call it again if the search value changes, and then with Vue.js, fairly similar, but they give you the on cleanup function as a callback argument.

So if the timeout changes, we clear it and then call it again if the search value changes, and then with Vue.js, fairly similar, but they give you the on cleanup function as a callback argument. So we can essentially set the timeout and then pass our callback to on cleanup, but this is similar to solid in that we could technically call it anywhere we wanted to. We don't have to return a function, and then with HTMX, they have this built-in attribute called HX trigger, and so basically we're saying we're listening for key up and changed, but with the delay of 200 milliseconds. So this will not make a request to slash search unless the event happened 200 milliseconds ago and a new one hasn't been fired. So they kind of, like, have a built-in way there of doing that set timeout. And so really all of these, except for HTMX, is kind of just set your timeout and then clean it up and sign some kind of callback. The way that you do the callback varies, but basically you have, like, a cleanup function.

All right. We'll talk about list rendering. We're going to fly through it, because I have some more stuff to show you, but basically in vanilla JS, we grab that results element from the page and then append to it. So this is a list item that we're going to create. So we're going to create a list item for every single result that we got back from the API and then appending all of those. You could also set innerHTML. We could build up an HTML string or something like that, a lot of ways to go about it, but in this case, we're just manually creating every single element.

And in React, of course, we can just use map. The thing to note here is we need a key, because we need to keep track of each element in case this array changes. So that's the key is allows the virtual DOM mechanism to make sure that if anything in the array changes, we're still good to go. Preact, very similar, but we're just accessing the signal value. Solid, a little bit different. They have this built-in component called four, and then it has in each property where you can pass in an expression. In this case, we're accessing results, which is a signal. And this basically needs to exist, because the solid components don't re-render over and over again. So we need to make sure that we're accessing all of the signals in the array. And so if you were to just do a plain old map, it wouldn't know that it needs to update. That's why they give you that method. And then you pass in a callback and you get your render.

Vue has a built-in directive called V4 that allows you to do item and items. You can then pass in the key, because Vue is a virtual DOM-based as well. And they also have this handlebar syntax. And inside of Angular, they have their own little language here. So at four, item and items. They also allow you to keep track of a specific key and they're using handlebars inside. And then Svelte has its own custom syntax as well. So this is hash each array as item. And then we can actually render it out using just a single curly braces there and then we close the block with slash each. And in HTMX, it's really dependent on your packing. So this is kind of like the full example with HTMX, where I didn't get to show this with conditional rendering, but if there's a request off to slash search, it's going to show progress, because that's the indicator of something happening.

And then when we get back to the results, the target is this results element here. And so the main thing to note is we're missing the server implementation, because the server actually needs to return that list of HTML that we actually appended to the page. And so all of these have a domain-specific language. I think even React and Preact, even though it's just a map, it's still weird JSX. So I'm calling all of this domain-specific language.

So there was the code. Let's get into some conclusions and where to go from here. The things that I wasn't able to cover is error handling, request canceling, accessibility, and a lot of other things, but ultimately the conclusion here is just use HTMX. I kid. Let's actually get a feel for the room. So I know this was a whirlwind tour and we didn't get to see all the bits and pieces, but who here is going to go home and just write themselves some vanilla JS? Nobody? Okay. Who's going to go home and keep writing React? Yeah, I think a lot of us kind of have to, because it's our jobs. Who's going to go home and write some Vue? Vue was cool, right? Vif, V4, Vmodel, it's got a lot of nice things in it. Who's going to go home and try Angular? I apologize. Yes, we got two converts, maybe you weren't in here earlier, but, yeah, Angular's the way to go. Who's going to try Preact? Preact is pretty sweet, and what's nice about their signals library is you can actually use that in your React app, and you can just show me your React app, and it's in there, and you can just look into it. They have a Preact React signals, and you can just keep using your same old React and add signals inside of it. Who's going to try Svelte? A few, yeah? It's also really cool. Who's going to try Solid? No hands. Personally, I think if we're gravitating towards newer frameworks that do things in newer ways, I think Solid is probably the easiest on-ramp for any React developer, because the syntax looks really good for it. Who's going to try Svelte? All right. Okay. We got at least three or four converts. That's awesome. Okay. And then, yeah, let's just talk about next steps. So, again, I just showed you the code. I didn't talk about all the other things you need to consider when you're choosing a front-end framework. The ecosystem, right? Are there libraries for maps and charts and everything else? Are there libraries for working with UI components, and what are the resources available, right? Are there a lot of examples out there? Are there answers on stack overflow? Was AI trained on Stack Overflow? Is there a community? Do they have an active Discord server? Are there active GitHub issues or discussions? And are there conferences and meetups? So, all of this stuff matters, I think, as well, when you're choosing your front-end framework. It's not just about the code.

These are the things to consider as well, and potentially a topic for a future talk. The other thing is about performance and how these things actually work, right? So, some of these frameworks are compiled versus having runtime code, and some of them use a virtual DOM. Some of them don't. Some of them have, like, a render cycle that works in a certain way. Some of them have fine-grained updates, and all of that is something you might take into account as well.

And, of course, there's not going to be one right answer. I think it comes down to preference, your past experience. Personally, one of the first front-end frameworks I used was Vue.js, like, version 1.4 or whatever, and so, for me, I kind of gravitate towards Vue because it looks similar to that older stuff. Some of you might have only ever written React in your life, so you might have never written React in your life, so definitely your past experience comes into play. The other thing is, like, what's right at the time? Like, if you work at a company and you're building a new app, like, what's popular right now, or what do my devs know? And maybe you make the choice then. And also, like I said, what you use at your job. A lot of us don't have a choice. You kind of just have to use what you use. And ultimately, I think it also comes down to vibes. Like, what do you vibe with the most? And ultimately, like, the reason I even gave this talk is I want to encourage you, like, explore, experiment, get out of your comfort bubble of, like, writing everything with React and see that there's cool ways to do things on the other side.

And the last question I'll leave you with is maybe stop thinking yourself as a React developer. Like, how do you answer this question? Like, are you a React developer? Are you a Vue developer, a preact developer, a solid HTML developer, an insert framework of the weak developer? Or are you a JavaScript developer? All right. Thank you very much. I had a question to start off. So, I know you put the HTML thing in there, but what's your, like, if you had to choose one, which method would you choose? Right now I gravitate towards Svelte and then also Vue. Like I said, I have a long love of Vue. I've been using it for a long time. And when Svelte came out, it was very much, it felt like the better version of Vue. And then when Svelte 5 came out, it was kind of like the second-best version of Vue. And then when I started using it, like, I was so excited. I was like, oh, I'm going to use this. And then when Svelte 5 came out, I kind of initially shunned at Runes. I was like, oh, no, it's getting more complex, but I've come around to it. And so there are some examples I didn't get to show. Like, with Svelte, they have this built-in, like, declarative await function, which kind of, like, could clean up the code and move it all into the template.

And then with solid, they also have this switch component. So there's other ways to write this that aren't just what I showed here. But Svelte or Vue would be my answer there.

Okay. Okay. And I have a question here from anonymous. Wouldn't we rather attach the request to the callback attached to the input debounce callback rather than write in effect to react to a state change? It depends, yeah. So again, lots of ways to implement it. They're also, like, if you're a React developer, there's a library, like, use debounce value, right? And so instead of combining the state update with the state update, there's also a library that's called use debounce. And so instead of combining the state update with the request, you could actually just have a separate state variable that only gets updated on debounce and then have a separate use effect that's dependent on that. I think that's kind of what they're getting at. Definitely a valid approach. Just not one that I showed.

And next up, another anonymous question. Why not just use the use debounce hook? Oh, okay. Because I wanted to show you how to do it yourself. I'm going to show you how to do it. So, like, I have a library that I'm using. That's the main reason. And I kind of just talked about it. Of course, if you have a larger code base, you don't want to be writing this from scratch every single spot. You might reach for a library that implements use debounce value. Yeah. But it's a great point. I think for a lot of this stuff, there are actually libraries that will implement this whole thing for you. You don't have to write any of the code. I think as an exercise in just seeing how things work in these frameworks that's a good opportunity to do that. There's a little version of this where you can arrow key down to select the elements. I think it's a good interview question because it's not just leak code. It's like, do you know the fundamentals of whatever front-end framework? Can you actually, like, implement these things? Okay.

Another one. We just have a couple more questions here. What are your thoughts on lit and or web components? Yeah. I haven't spent a lot of time with them. I think it comes down to, like, when you're even with lit, which kind of helps you reduce boilerplate when you're building out web components, there's still a lot of extra code you have to write potentially for, like, state management. Maybe you reach for another library. And it might actually end up looking a little bit like the vanilla example. But honestly, I haven't spent a lot of time with them. I probably should.

We have one final question. I know that you have been writing for a long time. How do you know all these languages? I have a lot of free time. And so I make YouTube videos for syntax. And I think part of my job and I guess also what I was doing for Coding Garden before I got hired at syntax is a lot of comparisons. A lot of people are busy, right? They don't have the time to do all this. So if I can be the guy that does it and summarizes it for you, I'd gladly do that. And I enjoy it. Like I said in my conclusions, there are cooler and better ways of doing things. It doesn't all have to be React. And I think seeing that and also getting inspired, maybe it inspired you to write your React slightly differently as well. That's something that I would want to do. So, yeah.

Awesome. Well, thank you. That's all the questions we have time for. But you can still ask questions after. CJ will be around if you have any more questions. So make sure to rate the talk on Slido. And we're going to have a short break so you can switch tracks. And so just check the schedule of the website to find out what you want to go do next. So thanks, CJ. Thanks.