A great search can make the difference between success and failure of your site or app. To develop a complex search UI on your own, customized to your specific needs, can be a daunting challenge. In this post, we’ll show how Angular’s component-based architecture can help. And if you’ve already built out your website with Angular, you’ll want to read on and see how you can quickly implement an Angular search box.

Why Angular?

First, let’s discuss if you’re using Angular to build your website. If you already are, great! You likely already know many of the benefits it can provide. If you’re not, let’s talk about what Angular can do and why it might be a good choice for your building website UI features.

Angular is a typescript-based language developed by Google. With this prominent backing, in addition to a vibrant community, it should have the resources needed to stay relevant throughout the upcoming years. Angular continues to grow in popularity, and the millions using it comprise a passionate community. Between that community and Google’s documentation, you won’t be lacking help.

Angular is useful for building dynamic web apps. You can create a single-page application with Angular, meaning your website can respond to users without constant refreshing. It’s also built for speed. How that is the case may be beyond the scope of this article (it’s due to its renderer) but regardless, expect your web apps to load with some gusto.

A key feature of Angular is its modular design. Angular apps are built with independent components. This component-based architecture is functional when building out complicated web apps, preventing your code from becoming messy and confusing.

Oh, and those components can also be from third parties! In combination with the robust community mentioned earlier, that means Angular most likely has the tools you need. Let’s dive into those tools some more now.

Setting up your Angular app

If you haven’t used Angular before, it’s easy to get up and running. The first thing you’ll need is a way to use the framework. Another part of Angular beloved by many is its powerful command-line interface. It can handle basically any task you’ll want it to do. Installing it is easy as well:

npm install -g @angular/cli

You can create a web app with Angular just as quickly. When you install the Angular CLI, you can call it using ng. In this example, we’ll be creating a web app called “my-first-app”:

ng new my-first-app

The CLI also makes it easy to serve your app locally. Just change into the app’s directory that the CLI created, and then run the ng serve command:

cd my-first-app
ng serve

The ng serve handles the building and launching of your app for you. The default template even points you to the documentation and provides some helpful tips! Angular-built apps have three important files (although, of course, this is a simplification):

• app.component.css
• app.component.html
• App.component.ts
• app.module.ts

As you explore the Angular process, you’ll work with the other files, but the content within these files will be most apparent when you look at your webpage.

Angular’s components — Making your app dynamic

Now, what about implementing components? As previously discussed, these are the building blocks of your web app. While you can create components manually, the CLI is the quicker option:

ng generate component my-first-component

This command will create all the files you’ll need to. These files are like the app’s files listed above, but only for the component. This means that you can truly have granular, independent control over what happens in a specific component. Components are referenced by the selector statement within the @Component decorator. The default is the component’s name, as we can see in the produced my-first-component.component.ts file:

@Component({
  selector: 'app-my-first-component',
  templateUrl: './my-first-component.component.html',
  styleUrls: ['./my-first-component.component.css']
})

We can also see that the same naming conventions apply to the component’s HTML and CSS files. This again gets at the modularity of Angular; these files are purposefully separated from the rest of your web app, and referenced when you build your web app. It certainly makes it easy to visualize what’s happening where!

But where are they referenced? Well, you can just reference this component in your app’s HTML file.

<app-my-first-component></app-my-first-component>

And with that, we can see our web app now just takes on the form of whatever is in our component’s HTML template:

Components can display dynamic information as well. For example, you can set variables in my-first-component.component.ts:

export class MyFirstComponentComponent implements OnInit {
  text = "test";
  constructor() { }
  ngOnInit() {
  }
}

Then, in your app’s HTML file, you can pull in those variables. In this case, the my-first-component.component.html is.

<h2>{{text}}</h2>

The web app will refresh to print that what that variable is set to:

As you can imagine, being able to change what the web app is showing dynamically is a crucial aspect of having a search box. After all, users will expect the page to respond to their search results! Of course, that’s after they provide a query. Let’s look at how that works in Angular.

Angular Events — Interacting with the user

Angular developers can create components to respond to user-based events. This can be anything from a mouse click to user text input. As you can imagine, this is pretty crucial for being able to search, as a user will need to be able to input their search query.

First, though, let’s look at how Angular handles events by looking at a simple event: a mouse click. Angular handles within the class of the component.ts file.

export class MyFirstComponentComponent implements OnInit {
  selectedText?: Test;
  onSelect(test: Test): void {
    this.selectedText = test;
  }

Then, you can specify how this looks on your web app within your delineated component.html file for that specific component.

We’ve looked at two essential features for a search box: a dynamic display of information and event handling. Now let’s address two other aspects of search: executing the query and building the UI.

Search-specific Issues

Executing the search

Where do search results and filters come from? It depends on how you want to access your data on the backend. This will be specific to your own situation, but it is something you need to think about when implementing search. Where will you be pulling this data from? And if you have enough data that you need to build a search function, you need to consider the best way to have that data accessible quickly and reliably.

For example, you might search using:

– A route defined to connect to your database
– An internal API built to share search functionality
– A basic hosted search service from your cloud provider

Whatever the choice, you’ll want to ensure speed and latency – this requires a performant search functionality and the best latency (one trip to the server). It also involves data storage and questions of relevancy.

Building the search

Angular’s component structure makes it straightforward to understand what’s going on at a high level, but you still need to build the individual elements of the interface. When it comes to search, you might be picturing a simple input box. You may also have some autocomplete features, which will need to appear as the user types. Even with the type-ahead experience, you’ll want a search button to round out the UI. Depending on your use case, there may be even more. Let’s look at the considerations for your Angular search component.

First, consider what you want your search box to look like. Angular gives you the opportunity to flesh out the HTML and CSS of components. You’ll want to style it for your site, but also for the search features it uses.

The second is to consider scaling, in terms of usage, but also search features. As demonstrated above, a proof-of-concept of creating an event-based component in Angular can be done without too much headache. That being said, what will you do when you need to expand upon your search functions? Many users expect to have the following features available when searching:

– Filters: Users want to control what type of results are being returned to them. Doing so means having filter-focused events that are waiting to respond after the search
– Pagination Control: Users want to have a controllable navigation experience through the search results. Perhaps they only want to see a few results at a time, or perhaps they want a never-ending scroll. Either way, they’ll desire something more than just a barrage of the entire results thrown back at them.
– Highlighting: Users want to understand why specific items were returned from their search. If the items are complicated, they’ll appreciate having the ability to see why they appear in the search results.

That’s a lot of aspects to consider! Of course, the Angular infrastructure allows you to build these features manually. You can create the interface with HTML and CSS, then tie in the appropriate events. Assuming your search backend can handle filters, pagination, and other features, you can work within Angular to display the results appropriately.

Angular’s component-based architecture also lets you take advantage of third-party libraries. When you build upon already-established libraries, you can focus on implementing these prebuilt (often pre-stylized) components.

A Search Library: Algolia

An example of a search-based angular library is Algolia’s Angular InstantSearch. Angular InstantSearch is built to save you from additional development time to create a search UI on your own. With Angular’s component-based structure, you can quickly implement this search functionality into the rest of your web app.

In the spirit of Angular’s modularity, Algolia’s InstantSearch library is based upon widgets. Widgets are the building blocks that make up our search UI. Which widgets you’ll use will depend on your web app. Algolia separates widgets within categories.

Think of widgets as the building material of a house. If we expand that metaphor, these widgets are different types of materials that are used during construction. It’s often a reasonable approximation to think of our library as a collection of pre-configured widgets. In actuality, you can be in control of more than you may think. By *extending* widgets, you can change both their behaviors and their outputs. The process for extending widgets involves using widgets’ business logic code (what we call connectors) and tweaking them to fit your own needs.

You can also customize these widgets for your specific use cases. Doing so is an intensive process, as it involves creating your own connector. That being said, we’ve got a guide for helping you create your own widgets. Even if you do build out your own widget, you’ll still get the benefits of Algolia’s flexible search infrastructure.

In most cases, you’ll find that building your own widget isn’t necessary, with many pre-built options available. For in-depth instructions on implementing the Angular InstantSearch library, see our Getting Started Guide or you can check out our Algolia’s flexible search infrastructure.