The document describes how to build an autocomplete widget using the YUI library. It discusses the key components needed: handling key events to detect when the user enters text, querying a data source to retrieve results, displaying the results, and wiring everything together loosely coupled pieces. These include a custom "valueChange" event, an AutoComplete node plugin to listen for this event and query the data source, a data source component, and a renderer widget to display the results. The document emphasizes that by building with loosely coupled and reusable components in YUI, the autocomplete can be implemented with only a small amount of new code.
15. Shopping List
• a way to find out when the user types
something into the form element
16. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
17. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
18. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
• a simple thing to wire it all together
35. // If you're LUCKY!
var foos = document.getElementsByClassName("foo");
for (var i = 0, l = foos.length; i < l; i ++) {
foos[i].addEventListener("click", fn);
}
36. // If you're LUCKY!
var foos = document.getElementsByClassName("foo");
for (var i = 0, l = foos.length; i < l; i ++) {
foos[i].addEventListener("click", fn);
}
// oh wait, that doesn't work in ie... fml.
39. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
• a simple thing to wire it all together
43. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
• a simple thing to wire it all together
53. Display
• Bounding box - need to manage position,
even when the window changes height
• Must support many different looks
54. Display
• Bounding box - need to manage position,
even when the window changes height
• Must support many different looks
• Overlapping anything (iframes, scrollbars,
select elements, other nasty creatures)
55. Display
• Bounding box - need to manage position,
even when the window changes height
• Must support many different looks
• Overlapping anything (iframes, scrollbars,
select elements, other nasty creatures)
• Keyboard navigation
59. with Widget you can:
• Fix the position of the box
• Skin it and change the contents easily
60. with Widget you can:
• Fix the position of the box
• Skin it and change the contents easily
• Overlap iframes and select elements
without any hassles
61. with Widget you can:
• Fix the position of the box
• Skin it and change the contents easily
• Overlap iframes and select elements
without any hassles
• Easily extend to support keyboard and
focus events.
62. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
• a simple thing to wire it all together
69. Shopping List
• a way to find out when the user types
something into the form element
• a generic way to get data from a server, or
from anywhere
• a way to display the list of items
• a simple thing to wire it all together
88. Signs you should add a
new Node event:
• It’s a very generic need related to a single
DOM element
89. Signs you should add a
new Node event:
• It’s a very generic need related to a single
DOM element
• The DOM implements something like
what you want, but not quite
90. Signs you should add a
new Node event:
• It’s a very generic need related to a single
DOM element
• The DOM implements something like
what you want, but not quite
• It “fills a hole” in the DOM API
91. Signs you should add a
new Node event:
• It’s a very generic need related to a single
DOM element
• The DOM implements something like
what you want, but not quite
• It “fills a hole” in the DOM API
• In other words, please don’t create your
own “click” event.
92. AutoComplete:
AutoComplete AutoComplete
Node Plugin Renderer Widget
DOM YUI Node
node Wrapper
Data Source
93. AutoComplete:
AutoComplete AutoComplete
valueChange
Node Plugin Renderer Widget
DOM YUI Node
node Wrapper
Data Source
96. AutoComplete:
valueChange
Listen to key events
Use setTimeout to defer value check.
97. AutoComplete:
valueChange
Listen to key events
Use setTimeout to defer value check.
See if the value has changed
98. AutoComplete:
valueChange
Listen to key events
Use setTimeout to defer value check.
See if the value has changed
If the value is different than last time, fire “valueChange”
100. AutoComplete:
AutoComplete
Node Plugin
Plug into a Node object
101. AutoComplete:
AutoComplete
Node Plugin
Plug into a Node object
It gets some settings
102. AutoComplete:
AutoComplete
Node Plugin
Plug into a Node object
It gets some settings
Listens to the valueChange event
103. AutoComplete:
AutoComplete
Node Plugin
Plug into a Node object
It gets some settings
Listens to the valueChange event
Fires “ac:query” event when appropriate
105. AutoComplete:
AutoComplete
Node Plugin
“ac:query” has
default behavior
Data Source
106. AutoComplete:
AutoComplete
Node Plugin
If not canceled, it
“ac:query” has
tells the data source
default behavior
to get some data.
Data Source
107. AutoComplete:
AutoComplete
Node Plugin
If not canceled, it
“ac:query” has
tells the data source
default behavior
to get some data.
Data Source
When/if the data returns,
it fires the “ac:load” event.
110. AutoComplete:
Extends the Widget class AutoComplete
When the user clicks on an item, call Renderer Widget
111. AutoComplete:
Extends the Widget class AutoComplete
When the user clicks on an item, call Renderer Widget
myNode.ac.set("queryValue", selection)
112. AutoComplete:
Widget gives it a bounding AutoComplete
box, an easy way to mange Renderer Widget
position, and a render()
function to make it visible.
113. AutoComplete:
AutoComplete AutoComplete
valueChange
Node Plugin Renderer Widget
DOM YUI Node
node Wrapper
Data Source
117. Loose Coupling
• Pieces should provide enough value to be
used alone or in other contexts
• Pieces should work with any other piece
that exposes the expected API
118. Loose Coupling
• Pieces should provide enough value to be
used alone or in other contexts
• Pieces should work with any other piece
that exposes the expected API
• “Don’t call me, I’ll call you”
events > method calls
120. AutoComplete:
Preview
What you are about to see is not even beta yet.
This is a slide deck, not an API doc.
Stay tuned at http://yuilibrary.com/yui3/ and
http://developer.yahoo.com/yui/3/
121. AutoComplete:
YUI().use("ac-plugin", function (Y) {
var myAC = Y.one("#ac"),
myDS = new Y.DataSource(...);
myAC.plug(Y.Plugins.ACPlugin, {
dataSource : myDS
}).ac.on("ac:load", function (results) {
doSomething(results);
});
});
122. AutoComplete:
YUI().use("ac-plugin", function (Y) {
var myAC = Y.one("#ac"),
myDS = new Y.DataSource(...);
myAC.plug(Y.Plugins.ACPlugin, {
dataSource : myDS
}).ac.on("ac:load", function (results) {
doSomething(results);
});
}); // wow, that’s a mouthful
126. Roll-up
• YUI 2 was a modular system - If you want
any part of a module, you get the whole
thing.
127. Roll-up
• YUI 2 was a modular system - If you want
any part of a module, you get the whole
thing.
• YUI 3 is sub-modular - Modules are
composed of sub-modules that can be
mixed and matched.
128. Roll-up
• YUI 2 was a modular system - If you want
any part of a module, you get the whole
thing.
• YUI 3 is sub-modular - Modules are
composed of sub-modules that can be
mixed and matched.
• Roll-ups provide convenience of YUI 2
modules, without sacrificing
customizability of YUI 3 submodules.
129. AutoComplete:
AutoComplete AutoComplete
valueChange
Node Plugin Renderer Widget
DOM YUI Node
node Wrapper
Data Source
130. AutoComplete:
AutoComplete AutoComplete
valueChange
Node Plugin Renderer Widget
DOM YUI Node AutoComplete roll-up
node Wrapper
Data Source
132. AutoComplete:
Preview
What you are about to see is not even beta yet.
This is a slide deck, not an API doc.
Stay tuned at http://yuilibrary.com/yui3/ and
http://developer.yahoo.com/yui/3/
135. In the final tally...
• Less than 4kb of new code, mostly for the
custom DOM event. (< 2kb over the wire)
136. In the final tally...
• Less than 4kb of new code, mostly for the
custom DOM event. (< 2kb over the wire)
• Most of the work consisted of arranging
and assembling
137. In the final tally...
• Less than 4kb of new code, mostly for the
custom DOM event. (< 2kb over the wire)
• Most of the work consisted of arranging
and assembling
• Good solutions don’t have to be hard
I&#x2019;m Isaac Schlueter, from the YUI team. I&#x2019;m here to talk to you today about something I&#x2019;m working on for YUI3, an Autocomplete module, and what goes into solving real world problems with YUI 3.
When I say "real-world" problem, I mean something that's an actual use case that real users are going to use. This talk isn't about a quick hack, or a proof of concept. Those things are great, and important, but this is about actually getting something done.
When I say "solve", I mean, I shouldn't ever have to deal with this problem again, and if anyone else uses YUI, they shouldn&#x2019;t either. I'm going to show that YUI 3 gives you the tools to do things in a way that is flexible, extensible, and extremely reusable, with not very much effort on your part.
So, yeah, I AM pretty lazy. But that's why I don't want to write the same thing over and over again. Cost matters, and that's the real value proposition with YUI.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
You all know what an autocomplete widget does. You start typing, and some suggestions show up. You type some more, and they get further filtered, or something different shows up.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
So, yeah, I really don't want to worry about all that stuff. I just want to make this thing work.
So, yeah, I really don't want to worry about all that stuff. I just want to make this thing work.
So, yeah, I really don't want to worry about all that stuff. I just want to make this thing work.
So, yeah, I really don't want to worry about all that stuff. I just want to make this thing work.
Doing things the first time, or creating a whole new way of doing things, that&#x2019;s pretty hard. I mean, it&#x2019;s hard if you want to do a good job of it. In this case, when we do things with the grain of YUI, we&#x2019;ll spend a lot less effort for a better result.
This is definitely a case of good laziness. That is, cost matters, so doing things with the grain is cheaper.
So, did I mention the site that this module is going on? It's fairly popular, maybe you've seen it before.
This is going on the yahoo home page, and in the search page, and the header that sits at the top of all Yahoo sites.
Between these three modules, about 7 trillion people view these pages every 4 seconds, so it has to work reliably, it has to load fast, it has to put almost no extra code on the page.
At this scale, every byte matters. By reusing as much off-the-shelf components from YUI as we can, we&#x2019;re going to save a lot of bytes.
It's gotta work with keyboards, or with screen readers, or with mice, or whatever else users decide to use.
But accessibility isn&#x2019;t just about blind people and devices. It has to work in all languages everywhere, because this is Yahoo, so just supporting America is not really an option.
Oh, also, remember those examples I showed before?
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
yeah, those
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
Thankfully, most of the hard stuff is already done. The main task here is figuring out how to use what YUI offers to assemble the thing we want.
The other advantage is that, by doing it this way, the little bit of code that we do end up having to write can be submitted back to the library.
For now, you can push code to github. People are doing this today.
Getting feedback from people using your stuff is addictive. Definitely watch for more collaborative features from YUI in the near future.
A lot of you have probably heard about some of these things already, and if not, I recommend going onto YUI Theater and watching the other talks, because most people who talk about YUI are way smarter than me.
But just in case, I&#x2019;ll go over some of the pieces that are relevant in this case.
Node is like candy for the DOM. It does everything you think it should do, and it does it in consistent and predictable ways.
This is the browser DOM API. Generally friendly, tries to do the right thing, but... a bit slow, mild stuttering problem, and... well... he&#x2019;s got no pants.
And, if you&#x2019;re in the unlucky majority that gets to support MSIE...
I&#x2019;m guessing everyone in the room has written this garbage at least once.
By contrast, the node API gets in there, does the dirty work that has to be done, and you never have to worry about it.
Surprisingly straightforward. Use selectors to get things, then do stuff to the things, and it all just works.
Well, I don't really want to worry about having to interface with a jillion different kinds of web services, and I *definitely* don't want to have to worry about caching and all that craziness. Data is strange, and I don&#x2019;t want to have to deal with it.
(yui 2 ds vs yui3)
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
So, some of these have more than just a bit of text showing up. In fact, almost all of them have some other stuff in there.
A widget is just a box. You put stuff in the box, and you can easily move it around, or put it somewhere, or whatever you like. You don&#x2019;t have to worry about what it&#x2019;s sitting on top of, because it&#x2019;s all tidied up for you.
The thing about putting stuff in a box is that it makes it a lot easier to manage, and a lot easier to move around.
The thing about putting stuff in a box is that it makes it a lot easier to manage, and a lot easier to move around.
The thing about putting stuff in a box is that it makes it a lot easier to manage, and a lot easier to move around.
The thing about putting stuff in a box is that it makes it a lot easier to manage, and a lot easier to move around.
Plugins in YUI 3 let you add almost any functionality you can think of to almost any object in the library. You can set up functions that get called when the plugin is attached, and the another function for when it's detached, and in between there, you can add whatever you want.
If you want to take an existing API, and extend it with some additional functionality, you can use a plugin to do that. Specifically, plugins are useful when you want to add on the features in a way that lets them be taken off again later.
Creating a plugin is easy. You expose one function that gets called when it&#x2019;s plugged into something, and another that&#x2019;s called when it gets unplugged (in case you have to do any cleanup)
Here&#x2019;s what it looks like when you&#x2019;re done.
Right. So, here's a pretty picture of the AC architecture.
[ad lib]
So, as you can see, it's very extremely straightforward, with no problems whatsoever. When the plugin gets plugged into a node, it attaches to the keydown event, and when the user presses a key, we know that something has been entered, so
In some languages, a single keypress event is not the same as a single character being entered. Unfortunately, there isn&#x2019;t any DOM event for &#x201C;onCharacterEntered&#x201D;
Also, if you&#x2019;ve ever tried to do much of anything on keydown or keypress, you quickly find that it&#x2019;s easy to bog down the UI and users get annoyed because they type and this thing freezes up as they&#x2019;re doing it.
What about onchange?
well, onchange doesn&#x2019;t happen until the user blurs the field.
Wouldn't it be nice if the DOM had some kind of event that would tell you that the data has changed, and did so asynchronously so that it didn't get all laggy and awful?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Wouldn't it be nice if the DOM had some kind of event that would tell you that the data has changed, and did so asynchronously so that it didn't get all laggy and awful?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Wouldn't it be nice if the DOM had some kind of event that would tell you that the data has changed, and did so asynchronously so that it didn't get all laggy and awful?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Wouldn't it be nice if the DOM had some kind of event that would tell you that the data has changed, and did so asynchronously so that it didn't get all laggy and awful?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Wouldn't it be nice if the DOM had some kind of event that would tell you that the data has changed, and did so asynchronously so that it didn't get all laggy and awful?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
In fact, if you use the focusIn and focusOut events exposed by the Node API, you&#x2019;re already using custom events. The really nice thing is that, when an event can be done natively, you can do it that way, and when it&#x2019;s not available, you can sort of roll your own based on other events that do exist.
There&#x2019;s just a very slight change that you have to make to your code if you&#x2019;re using a custom event vs a regular DOM event.
Here we see a click handler being attached to a YUI Node object. Notice the stopPropagation and preventDefault that you know and love from the DOM.
And, here&#x2019;s the same Node object listening to a custom event.
Oh, I can see the blog posts going out now &#x201C;Much Hyped AutoComplete Module Doesn&#x2019;t Even Work&#x201D;. So, I put this scary warning here for a reason. There&#x2019;s a good chance that this is pretty close to what the final code will look like, but this is a slide deck, not an API doc. You can be sure that, this being YUI, there&#x2019;ll be more documentation than you can shake a stick at once it&#x2019;s done.
So, if we just pull in the AutoComplete node plugin, and attach it to a dataSource, we&#x2019;ve got a way to very explicitly decide what happens at each point. Of course, the &#x201C;doSomething&#x201D; function here would be connecting up to our ACWidget.
But while it&#x2019;s good to be able to use AC however you want, it&#x2019;s also a bit of a pain to have to do all this for just the simple/common use cases.
What if there was a way to take the common use cases, and make them simple?
Set some defaults, package it up nice, and then when I just want the basic/common autocomplete, I can instantiate it without all the hassle. That means that you don&#x2019;t need to know how autocomplete works in order to have it work for you.
Chances are that this will be part of the YUI 3.1 which if I&#x2019;m not mistaken will be out in Q1 of 2010.
If you really can&#x2019;t wait, then you can always fork yui3 and follow the progress there. Also, YUI 2 has a great AutoComplete widget that works, and is in use all over the place. I highly recommend it.
