Material-components-web: Searchbar Component

[ZanderBrown]

Opening an issue here per @Garbee's suggestion.

It would be great if MCW had a search component, similar to if not based on @eKoopmans proposed component for MDL (https://github.com/google/material-design-lite/pull/5061)

@eKoopmans original PR message:

Description

This is an MDL search component based off of this Material.io spec. It features an input field, dropdown search suggestions, and responsive back/cancel buttons. Search functionality is exposed by two callback functions, search and submit, which are specified as text attributes on the component.
The component is loosely based off of the menu and textfield components, which allowed me to maintain some style consistency with those. It can be styled as an inset box (i.e. "Persistent search" in the Material.io spec), a full-header search field, an expandable search field (i.e. "Expandable search"), or an unstyled inline block. It also works in combination with mdl-textfield styling, which is demoed in the snippets.
All documentation and testing is done, though I could use help with further cross-browser testing!

... basically sums up what we are looking for here.

For a visual guide with have @eKoopmans original demo and documentation

Both @eKoopmans & @eklem have expressed an interest to work on implementing this

[eKoopmans]

Hi, I'd be happy to port the component to MDC-Web, and I'm open to guidance regarding the implementation. I'll work out an Engineering Outline Document when I have the chance.

There are a few details that are not explicit in the spec (i.e. sizing/spacing, I guess because the spec is defined as a "Pattern" and not a "Component"), so if there are any decisions regarding those I can incorporate them. When in doubt I tried to follow the styles used on the Google Maps search bar.

[touficbatache]

It's probably not something that would be natively put as component / in the toolbar. So the philosophy with MDC-Web core components is as _unopinionated_ as possible about how people might use the components. One major criticism on Material Design is that the way to do things is too _opinionated_. The search is really great but it may not be the way some users _want to do it_: this means they would either have to hack around or replace it completely. It could be made optional but then other users could create other patterns for the search and figure out that they can submit it and see it in the codebase as well. WDYT @traviskaufman @amsheehan ?

[amsheehan]

I think the points @touficbatache brings up are fairly aligned with what we're building for MDC. Search is a pattern. This means that while you can _use_ MDC Web components to build out a search experience, we are merely providing guidance on what one should provide.

We currently have no plans to implement the Search pattern as a component as it exists in the Patterns section of the spec

[eKoopmans]

Okay I understand, though it is disappointing. I would say that apart from sizing details (which can be tweaked easily in CSS) there's not too much opinion involved in the implementation - the spec spells out fairly clearly how the component should look and behave already.

I understand that the MDC-Web priority is unopinionated adherence to the spec, but I'd like to offer a different perspective. For users like myself, MDC-Web (and MDL before it) are the official Google implementation of Material Design for the web. Google made a big push promoting Material Design as a universal style that could be used for every app, and that makes developers expect an easy-to-use, complete package that they can use to get up and running, provided by Google.

Search components are a very common piece used in many apps, and it's a pretty glaring omission for a developer wanting to quickly build an app. It's a lot to ask for each developer to build their own search component, especially if they want one that adheres as closely as possible to the rest of the Material Design styles and behaviours. So I understand the conservative approach, but I think from a user's perspective it's frustrating, wanting to use the official implementation but missing some crucial pieces.

[touficbatache]

And maybe other users don't like this implementation of the search? Maybe
another user built another one? He may also open an issue asking for his
search implemented: the search has many ways of being done. Your search pattern is really great but I don't think it can be implemented for several reasons that you could discuss with the developers.

By the way, check out the search circular reveal I made, demo at https://mdcwp.ml/

[eKoopmans]

And maybe other users don't like this implementation of the search? Maybe another user built another one? He may also open an issue asking for his search implemented.

As use cases emerge then changes can be made, isn't that how open source works? That process can't start until there's a starting point. But changes (and initial implementation) would be done with the goal of being as unopinionated as possible.

The search has many ways of being done.

Sure, but the spec is actually pretty specific about a lot of those details, which I have tried to adhere to closely. In any case I'm not saying my implementation is the right one, but it would be great for a search component to exist.

By the way, check out the search circular reveal I made, demo at https://mdcwp.ml/

That is pretty cool, and I see the point that things like that are not defined in the spec and could be done many ways. But it seems to me that with an existing unopinionated component, styles like that can be added by developers for their own projects fairly easily.

[eKoopmans]

On the topic of unopinionated: there are ways to bake that into the component. For instance, I provided a default "dropdown list" behaviour for search suggestions, but I've also provided the option to display the suggestions in any other element, i.e. if you want the suggestions to appear in the main body of your app (or not display at all). This both adheres to the spec (which suggests dropdown) and stays unopinionated by natively supporting any other design choice.

Likewise, the appearance of the search component itself is unopinionated. It can be styled many ways, including two default appearances suggested in the spec (inline and expandable), but any other appearance can be achieved with minor CSS styles.

[eklem]

I'm with @eKoopmans. The typeahead module from Twitter that is ported everywhere is a really opinionated module. This is not. Autosuggest/autocomplete has been a well established pattern for a long time. It has some variations when it comes to content in what's returned from a matcher.

I've earlier looked at vue-strap's typeahead module, but it was technically to bound to certain services way of communicating, so it was a no-go. I'm a search engine guy and got really happy since eKoopmans addition to MDL was open enough to be used to a lot of different use cases surrounding search and autosuggest / autocomplete.

For me it sounds like you are setting up a too future proof approach. Isn't this why we have major versions for when stuff is not backwards compatible?

[Garbee]

Isn't this why we have major versions for when stuff is not backwards compatible?

Incompatible changes still need to be kept as minimal as possible though. Developers don't like needing to handle a breaking change update every month as things change.

---

On the note of patterns compared to components. Components (what MCW focuses on providing) are individual items of the specification that can be used individually of each other as much as possible. A pattern is an app-level state or more details on how to handle individual components when the app-level state changes. The pattern in question is an app-state level thing which may have an affect on another component (toolbar) in some modes. This makes implementing it cleanly and maintaining it fairly difficult from an internal perspective.

While it is sad this won't be an internal piece I completely understand why the team doesn't want to take this kind of thing on here. However, no one is discouraging this from being its own component maintained independently to depend upon MCW. This is a great opportunity to make a community maintained package that provides the pattern. Then later on if it should prove useful/widely used enough then it could be assessed if it should be pulled into core. Or if the project could provide a curated list of community packages once there are a few of good looking quality available.

[eKoopmans]

Hey, sorry I dropped off the conversation, it's been a busy week! Independent component, okay. The nice thing about MDW is that it is inherently modular, so that should be cleaner than it would have been for MDL. Anybody seeing this in the future, feel free to contact for an update, this is on my list but it's not a top priority, so it may be a while. Thanks!

[eklem]

I'm not a good programmer, but I'll test whatever you make, @eKoopmans !

[dandv]

Can anyone recommend an off-the shelf MD expandable search component?

@amsheehan and @eKoopmans: the link to the search pattern now redirects to https://material.io (which BTW has a simple search overwriting the app bar). Is that pattern still specified anywhere?

@touficbatache: that link is dead

[touficbatache]

Hi @dandv, check out http://toufic.000webhostapp.com instead of the other link!

Edit: Yes, the search pattern can be found at: https://material.io/design/navigation/search.html#

[eKoopmans]

Hi @dandv, good luck, I hope you find a good solution!

[dandv]

@eKoopmans: react-md has implemented some important controls that MDC for Web lacks: autocompletes, tables, and also this search bar as part of a toolbar.

[im-n1]

I just wanted to add search bar into my app and realized that its not implemented. So I've tried to put an text field into top app bar like:

section.mdc-top-app-bar__section.mdc-top-app-bar__section--align-end
    .mdc-text-field
        input(type="text", id="my-text-field", class="mdc-text-field__input")
        label(class="mdc-floating-label", for="my-text-field") Hint text
        .mdc-line-rip

and it's not even visible.

So I was thinking :thinking: ...

• search functionality is number one functionality on the web (hello Google)
• implementations:
  
  
  
  • vue-material :heavy_check_mark:
  
  
  • vuetify :heavy_check_mark:
  
  
  • old MDL :heavy_check_mark:
  
  
  • vue-material :heavy_check_mark:
  
  
  • react-md :heavy_check_mark:
  
  
• on the guide page of App bar the search can be seen on any other screen. Even the page itself has the search in the top app bar.

Maybe we are missing something here.

[touficbatache]

Material Components Web has been made to provide Material Design Components that you can use on the web, so the functionnality of the Search should be coded by the developer and not this project. Material Components is also very different from all of those projects, as the philosophy with MDC-Web core components is as unopinionated as possible about how people might use the components. As for the guidelines, there are still no specific guidelines for how the Search should look like and it's up to the developer to choose which pattern to adopt.

[im-n1]

I get that, you are right - sort of. I'm not saying we need a fancy search widget. It would be absolutely enough if an text field (or mdc-field) could be placed into top bar (left, center, right position). That doesn't work at all (the input is not even visible for some reason).

So if we could place components one into another we could do many things. Search bar is nothing more than a form with one text field that takes user to the search results page.

It seems to me that the top bar has "aggresive" styles so when I put anything inside I can't even seen it. I would happily code the search feature by myself and share the code for other guys but.... I can't.

What do you suggest?

[touficbatache]

Take a look at https://www.batache.com/ where I coded a search bar using MDC. You can also read my Medium post about it if you're interested in knowing how I made it :smiley: https://medium.com/@touficbatache/how-i-coded-the-search-reveal-animation-for-the-web-85b8048091fc

[im-n1]

Amazing. Thank you for provided info. I will let you know once I find some time to dive in.