YUI Library Open RoundTable, 3 Apr 2014

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: YUI Open Roundtable with Tilo Mitra on YUI and Hammer.js

Description

YUI Open Roundtable is an open forum for all things YUI, javascript, and Front-End technologies.

A

All right, we are.

B

Live today is thursday april 3rd.

C

From 14. it's.

B

Our next uh edition of the yy open round table we have with us um is our guest, teomitra and georg. What's your last.

B

The creator of hammer, js and hilo is the creator of the integration of hammer js with yui. Potentially so we could just go ahead and get things kicked off. Tilo uh go ahead.

D

And take it away, oh okay, sure um so I've been working on trying to figure out a way to bring better gesture events to yui for a while. Now and I've been a big big fan of hammer, uh I think they do a lot of things right so uh credit to jorik for doing that. um So I was looking into oh hold on someone's calling my house here.

D

Okay, um so I was looking into trying to figure out how to like best um integrate hammer.js with yui, and I have something working, so I thought I wanted. I wanted to demo it to you guys um so the people who are watching this and they don't know what hammer is, um I guess, you're you're the best person to like talk about it. Do you want to like give a brief feel about what camera does yeah sure.

E

Yes, it's a small uh library, that's just uh rigorous uh gesture events like swipe tab, double tap, hold, etc, and it just simplifies the whole implementation, because otherwise you have to do like the all the touch, events, the mouse events, the pointer events etc, and it's a lot and then they have to have the difference with ios and android and uh well that's that's kind of a hard job to do it right, and this simplifies it a bit and.

D

Yeah, the most important things that I liked about hammer is one it has no dependencies uh core has has no dependencies, it's just raw javascript and two um apart from just kind of um simplifying and normalizing the gesture events.

D

Hammer also provides a very rich set of properties for every event payload, and that really helps you kind of figure out uh what to do with this event when it comes in so so, those are the things that I really like so I'll I'll just screen share and talk a little bit about what I've been working on and how it relates to to hammer specifically all right.

D

All right. Can you guys see my screen here.

B

Yeah, it's a little small, the tech, the font size.

D

Yeah, uh the fonts aren't that important here I'll I just bumped it a little bit though um so I made.

D

um Yeah, so this is like a standard example that that hammer has, for um you know, as you interact with the page here, you'll see that different events are fired and, as the events are fired, they light up in green here. So, as I kind of uh as I tap on this page, I get a touch event. Then I get a tap event and then I get a release event when I, when, when I release my unlike mouse end or something so so, each of these events also has this payload, which I was talking about.

D

So each event has like touches angle, a lot of really useful information here. um So I basically took this example, and I and the example you're seeing here is using yui's hammer js um like it's using hammer just under the hood, but it's using the yui uh interface event interface to get to it so I'll show you I'll show you the code for how that's working.

D

um So let me bump this up a little bit, so you guys can see.

D

Can you guys see that is that clear enough yeah, that's good, yeah, okay, cool, so in terms of the actual the actual source code? For that page basically, what's happening is something like um something like this, um and the standard use case is more like something like that.

D

um So I'm saying the hit area, which is this node with an id of hit area uh on tap log event now, instead of doing on tap, I have this. We have this array here which has all the events that that hammer has and whenever any event comes in, I'm logging it. But basically this is the interface that that you can work with when you have with this with this layer that, like interfaces with hammer.js under the hood, so this is very similar to any other yui event right like we in yui.

D

We have things like you know, like I don't know on hover and on, like focus so using a similar concept except you're delegating to hammer.js under the hood here. um So I got that working which is nice and then the other. Another use case here is event delegation which actually george kind of helped me out with last night, but I kind of figured out this morning.

D

um You can do something like this so y dot, one body so on the delegate to the uh event listener on the body for a touch and when the touch comes in um and and yeah, and it's like it's on a div uh log log, the event. So let me kind of show you how this works, so so you can see that that'll give me the touch here. But if I go up here somewhere, you don't get a touch um so just standard event delegation, but that that works really nicely as well.

D

um There are some benefit like some like little useful things that we can do when we subscribe to uh when we use yui specifically so, for example, yui has this concept of using um after so you can do something like hit area dot after tap. You know do something, but you can also do like hit. Area.On tap. Do something um so you could. You could imagine where you want to have the after listeners fire after the on listeners.

D

So this is something I was going around with just to see is something like this possible where, um even though you subscribe to them in this order, what you want to happen in the code is when this runs you want to have on uh logged out first, and then you want to have after logged out. So I think that that works too yeah, so you'll see.

D

No actually this this is this is actually broken. I should double check this because um the after actually comes in earlier, as you can see in the milliseconds here, so I got I got to fix this. Actually, that's that's! Actually what I was working on last um so got to figure that one out um and then the other thing that I kind of I kind of did was and uh uh jorax here.

D

So maybe he can like help help help me figure like tell me if this is correct, but um I created this um this property on a node instance, um this attribute or notice. It's called gesture, ops and basically the idea here. Is you say that, on on a specific gesture on a specific node, you can say hey for this note, these are the gestures, and these are the options that I want to listen to. So one of the things that we didn't mention is hammer.

D

Has this very like another, a rich set of options that you can listen to for every gesture, so I'll pull it up here.

D

Go on on like a per gesture basis, you have all these options that you can set things like when you're dragging this. Should I lock it to the axis. Should I have like a max touches? Should I prevent default?

D

Should I prevent mouse events um a lot of a lot of like really specific uh implementation, details right, yeah, which is really cool, um so what I've done here is you can set these options on a specific node, so here I can do something like you know like prevent default uh faults, and then what happens is when you. um So let me just turn this back to. Let's turn this back to hold.

D

When you um listen, when you subscribe to an event on a specific note, it actually under the hood, goes and pulls out this gesture options and applies these options to the hammer instance that's created under the hood.

D

Does that make sense.

C

So people are saying globally to like if there are like global options that you want to have.

E

E

Most of the time you you should, you should just use the use, the default options, yeah.

F

E

You can like specify a bit like. Oh I I just want one to one once I don't. I don't want a any event or something and yeah.

D

Right, so so in so in this in this case here what will happen? Is um you have this? If you have this code and you run it hold, will actually not get fired because I'm setting hold false and then I'm setting I'm saying, hold false on the hit areas, gesture options and then I'm saying hit area dot on hold. Do this?

D

Well, it's going to say yeah yeah, but you have hold faults here, so I'm not going to I'm not going to I'm not going to run that so that's kind of the analogy, that's that's being used for each your. Your gesture options are set on a per node basis.

D

Is that exactly? Does that make sense like? Is that intuitive, because that that's? What like eric- and I were talking about this this morning,.

E

Well, you shouldn't set it on a note, but more on.

E

Have a different uh setting for each note, but more on on the main instance.

D

I guess right now, what we're doing is we're saying each hammer instance is tied to a node. I mean similar to how the jquery um yeah yeah nothing works where, like each element, has a hammer, yeah and then each hammer is the option.

D

It's really tied to the node. Isn't it yeah.

E

Yeah yeah yeah- that is true, and in that way now I was thinking more in the in the in the in the uh depth of the of the of the of the event, the delegation.

F

But but that's not to your.

D

Yeah, so I'm doing something very similar to what you're doing the jquery plug-in. So if you look at this method, this is again. This is under the hood. What's happening.

F

D

You're, actually initially what's happening, is I'm saying: does the node have a hammer instance associated with it and if it doesn't create a new hammer instance pass in the gesture options that you get from the node.

G

D

And then you know store this um and and if, if if it does have a hammer instance, then then update the options with any updated options that you find. So I think it's exactly like I. I basically took this from your jquery.

B

Practical example of this like, why would you want to do this like? Is it? Is it like a state where, like you know, you're already dragging something, so you don't want other events to get fired or no.

E

That shouldn't be, but like the like, the like the swipe event you can set like uh respond to a speed of like offered two or two, a velocity of like an of like a dot, is zero.

E

Okay, now that 1.7 or something is it's like the default, but maybe on a bigger uh place, you want it like, like a different threshold, so you can change the settings for it, but it shouldn't be needed.

D

In most cases, yeah in most cases it's not it's not really. The defaults are actually actually really good, but the idea here is and and like people who, who are using yui, will kind of understand generally what we used to do in yui. Is we used to do something like this? We should we normally do something like so I have.

D

I have I'm like subscribing to some event right and normally what I would do is, I would say I would do something like this right forget forget everything up here, um the I pass in these options directly to the event subscriber right, but what I'm saying is uh eric- and I have been talking about this- is in the case of like these gesture events.

D

What you actually want to say is this is how I think this node should behave so when this, when this specific node gets any swipes or drags or taps, this is how it should behave, and then I set up. um You know specific events on that note, so intuitively it makes more sense than having like this sort of philosophy where you pass an options on a per subscriber basis, because this is actually going to lead to a lot of bugs when you're hard to crack down yeah.

G

D

It don't update where you everything exactly.

G

Yeah, so here it's on inside, like a global node level, uh just your apps like a a free form list.

B

Or is it a set list of things like hold as a specific label? uh Sorry, can you repeat that so the gesture options there's a limited set of those right? It's not just uh you're, not just like free form, sending parameters through right, no.

D

So yeah, so these are all the options that hammer has yeah. It has about like a good good bunch of them. um These options include, like things like for specific events, so for they're prefixed, so these are like for drags and they also have they also have like. Should I fire this gesture so like hold true release?

D

True, like should I be firing these and you shouldn't be modifying these too much from what I understand but they're there if you want to change them right, right, yeah- and um I we should have probably touched on this earlier, but like this, these are all the hammer. Events that like these are all the events that are supported by hammer so they're, like very it's a very rich set, um pretty much most of like, like anything you want to do.

D

You should be able to figure it out by using these events and to put in perspective like right now, yui has tap.

D

Touch and release, but like so it has like very very few of these right. So it's a good way to get a more rich set of events in here. We don't have drag, we have drag, but we have like we don't have like you know you have like drag drag like you have to instantiate a drag instance.

D

You can't drag a no like you have to plug in a dd to a node. It's not as easy as this and hammer has a multi-touch events correct right. So that's really cool and I wanted to demo it. uh So if I go, let me first like open up um like I'm emulating my touchscreen here, so that I get some touch events coming in here and then in this example, you press down shift.

E

Now but you don't have to uh go in the in the in the into in the inspector, uh you can put it off.

D

Oh, I think I do. I think I broke some or I I just cancel out all the events or something oh yeah. I gotta like turn this back on.

B

C

You close the top one, so while you set that up, I hatch is asking all the config values that you have for the options. Will those change to uh camel case uh soon to like fit like yui, because yui is like all camel case otherwise, right now,.

E

Is that a question to me or.

D

I guess it's a question. I guess it's more to me but like why ui is depending on hammers. I wouldn't. I wouldn't change these to camel case. What I would do is if we were going to go with camel case. I would just have like a you know like a hash table which takes whatever like camel case. You have and applies it to like this under the hood.

D

So I would just.

E

Yeah yeah yeah sure, because there are also a lot of other people who use the the code base and- and I can't change this settings like like like this yeah. So that's something that we would do on the yui.

G

B

Yeah the the goal would be that just bring in hammer js in place without any edits, and then why why to fly its own changes? On top of that.

D

Yeah, so what about what I'm doing now is I'm actually pulling a hammer through bauer and then um I'm just you're you're you're, adding bow of hammer to the page and then you're, adding in this module that I wrote and then you can use like yui with hammer easily. um So this is the this.

D

Is the tran, the multi-touch thing which is really cool, so you, if you pay attention to the event data as I do this, so I'm pinching in now, so you get the pinch in and you get like the scale property going down and as I rotate this, um a rotation property, that's changing, and then I can like pinch back out and so yeah, it's really nice. I wanted to ask your like what are your plans with this? Like are you? What else are you thinking about doing with the library.

E

Well, I want to maintain it. Oh, I got a my my girlfriend, just something I I want to maintain just for for now and and and they and these things like to like the like the faking, the multi-touch is just an um sort of a sort of extra tool for from for making debugging easier yep, but I don't have like real future plans, which I just.

F

Want to support.

E

And then it's now like uh two years old, I guess the whole library and I still support it and.

D

It goes okay, so yeah, so one of the cool things is like if we see any bugs coming in on the yui side. I actually know the hammer source code pretty well now, because I've been looking at it for like a while, so I can definitely send you some issues and pull requests. Yeah sure one thing I wanted to ask you is um so with like: have you have you fooled around the css touch, action, um property and and like? How does that apply? To like? I guess, does hammer not worry about that at all.

E

Well, yes, there is because, because it supports pointer events and now the default touch action is at none.

C

E

And that's a pretty uh hard decision because it will because it will block, like all the all the pointer events at that place. Yeah and I and I I I'm thinking about it- to change it to like pen uh x, up and uh yeah x. So it just blocks the vertical scrolling and that is seems like a more uh uh better default.

D

Yeah, because that makes sense like vertical scrolling, you're scrolling, the page horizontal scrolling. You want that to come into the javascript.

E

Yeah yeah, and that should be, I guess, a better default, because uh most people just just want to swipe, left or right and nothing up or down.

D

Yeah yeah, that makes sense.

E

So yeah but yeah, it's like it's like it's like open source and on. I know, and I know github. So if you see any bugs or issues then yeah you can just send and send a pull request.

B

Versions of the jquery plug-in is that how we would have to provide support for ie.

D

um So I think jory can speak to this, but it actually the it has really good compatibility.

E

Well, the compatibility for older uh ie versions are browser anyway. It's it, it really depends on like uh the window uh ads uh at event listener. That's like the main issue. I guess what what it separates from using at uh ie, seven, six or eight.

D

Like eight also yes, so one of the things I'm working on now is to and and correct me if I'm wrong, but what you do with the jquery plugin. Is you delegate it off to the jquery's on method which has uh which has support for older eyes, because it it it doesn't use ad event, listener, yeah, so yeah? So I'm trying to do something similar with that to delegate it off to yui's equivalent, um but once I do that it should support ie, seven and eight as well.

B

You know: do you foresee like contributing this back to hammer or just having it as a add-on for yui.

D

Well, what I'm trying to do here is is to basically not change hammer at all and when, like I think, the source code for hammer is written very well.

D

So whenever I need to modify something I just modify, you know it at the prototype level, but basically why ui is depending on hammer, so hammer shouldn't need to change anything at all, we'll change what we need to to get it to work with yui and then what this allows us to do is like if we have any any bugs on on, like that people uh like find out- and we realize okay, this is like a hammer js bug, then I can actually work directly on the hammer.js source code and issue a pull request there.

D

So at least our changes are are in one place.

B

Maintaining a hammer, if you have any future plans for you know like windows, 8 stuff, you know new windows features or things like that.

E

Well, yeah, it's it's! It should uh already uh support windows 8, because it's a support, support events, but I never had really the chance to test it on a real windows, 8 device.

E

So but I get a lot of people who uh also use helis on a windows 8 device and that works, but like in the future support I would like to make in the next version, like the v2, the multi user, uh also something because because now it only works like when, like when you uh use it on your phone, but not on the under on the larger uh touchscreen device that are also coming up like the big microsoft like attached tables or something I don't know how they called it.

E

uh I believe microsoft's surface, but on the bigger tables. Also, the multi-user.

D

Right really makes sense, yeah.

E

But uh like a future plans to support the the multi-user input, okay,.

D

Yeah, so it looked, it looked really stable, like I tried like breaking it by like doing the weird things with my fingers, but it it, it seems to hold up really well. Are there any like glaring issues that you're aware of that, like you're, trying to fix right now.

H

Well, um I I I there's a a small issue. I get I I think they're like um when you uh the.

E

Last event, because when you're uh uh uh release on all the fingers of your touchscreen, then you get no uh real good uh touch event uh touch uh and event it. It doesn't contains all the event data you want, so it's so it uses underneath the the last event, sometimes so the lights movement event and it it doesn't really matter so much for the user.

E

So it's it's like it's the the finger moves like one millimeter or something, but uh it is not like the the the uh the exact last place they have touched, but the user won't notice it. But that might be a a bug I I want to fix sooner or later, but it's not like major issue or something.

D

Cool yeah, it makes sense, and and it's funny this is not directly related but like we actually like eric- and I originally like- talked to joric when we were working on pure stuff because he wrote the grunt strip mq plug-in, which we went in like kind of overhauled, because we were using it for pure. So I actually, I actually knew. I actually knew you guys the hammer chest that before that, but then, when we were doing the strip bam q series I was like. Oh, this is the same guy. That's that's right!.

E

A pull request to the new uh fuzzy fuzzy testing tool like a.

D

Yeah, I think I saw that on twitter is that using that new gremlins thing it's like gremlins.js or something like that- yeah yeah yeah. I think I saw that on twitter, for you.

B

Tilo, what what can you tell me a little bit? One of the things that I think that's implied here, that we've already talked about is that you were able to do this pretty quickly, because you had experience doing this through pure right. You already know knew a lot about how to bring in a new library into yui.

D

uh That wasn't really the hard part, because all I did there was. Why do I have a bauer jsp file, and I just added hammer to that, though I think the hard part was like understanding how yui synthetic event system works, so understanding how to how to create new synthetic events then figuring out. Okay. How do I do that now with events that.

F

Are already in hammer and then how do I delegate.

D

My work to hammer to so when someone says on tap. How do I tell hammer a hammer? Do this on tap like under the hood having a hammer instance and all that sort of stuff, so uh I think jorik's code for uh the jquery hammer, plugin kind of helped me out a little bit there, but there was also some like yui idiosyncrasies, which I just kind of had to like just kind of trial and error and figure it out.

D

And once I had like some proof of concept working, it was just about like making that better and better.

B

So what do you think about performance since you're sort of passing things off? You know.

D

Under under the hood, is there a performance hit, or so I don't there's. No real performance like camera is a very small library about 2kb, so I was able to actually unders like I went through the source code and kind of understood what it was doing under the hood and basically what happens is when you create a new hammer. Instance.

D

Hammer basically sets up about four event: listeners on the dom element uh and they're event. Listeners for, like touch start touch, move based on based on what kind of you know, device, you're, using mouse or touch or pointer, and so what we do is we say: okay for each node have a hammer instance. So for each node create four event listeners and then that's it. We only instantiate a hammer instance once per node. We store it off dom so that um so that we can retrieve it quickly.

D

We don't have to like read and write to the dom, and um so in terms of performance, it's actually yeah. I don't. I don't foresee any issues I haven't done like performance testing on it, yet because it's a little tricky to do like event, performance testing, like it's very hard to like simulate that right but yeah, I don't foresee any any any issues with that like the quote, I wrote is about like 60 lines, long and no loops or anything, and then hammer is not that big, either yeah.

D

Okay. So what's your plans for moving forward? So what I want to do is try to polish this up and then release, uh hopefully bring it into yui in the next version of yui. So then um the yui supports hammer as of like their latest version and then as hammer updates, we'll update our uh bauer json file to like pull in the latest changes, um and so I think originally what I was doing is.

D

I was trying to create these events from scratch, and then I realized that hammer already does a really good job of this. So if we can figure out how to make it work together, then then it it's better for both all like for everyone. So hopefully this will land in yui. Shortly after uh we fix up some of these bugs and.

C

Will this be backwards compatible with like, um like the old touch events in my one, I.

D

Think we'll probably deprecate those okay yeah for a while you'll have both.

B

Libraries in there right.

D

Yeah- and this is actually richer and and yeah it's just more stable- it's been tested, more more people have used it, so I make sense of deprecate or what we have currently once once this comes in. What I will do is uh I will actually help with some of the documentation on the hammer.js side um and maybe with some more examples.

D

I think that would be. That would be helpful too. So yeah I'll I'll definitely send you. Some pull requests for that.

G

How will you be able to choose between? Will there be like a flag, you have to set um or just be a different syntax. So you just whatever you need it's.

D

The exact same syntax, so that's that's what I tried to maintain the exact same syntax and basically, what you'll have to do is pull in a new module, we'll call it like event hammer or something. So you put a new event: hammer module and suddenly you've got all the hammer. Adjusted and it'll be the same way that you currently use yui events.

B

Hopefully, you'll handle all the versioning stuff like when there's a new version, we'll just hold it through power again.

D

Yeah yeah and from what I've seen hammer is like really good at like um saying like when new versions come out and and and listening some of the changes. So I think it should be fine.

B

And it looks like the license is compatible. So that's good. It's good enough.

D

B

I

That's great, did you have any other questions about? uh No, let's uh did anyone else in irc have any yeah? No, I think that's so. You've you've tried this on device stilo and it works.

D

Great yup I've actually fooled around with it a lot uh over the last few months and uh yeah. I mean that's kind of how I got to know about it. So yeah, I'm really happy with it.

E

Or something some some, some some, some, some really big sites use it now, like the movie database, the emd imdb, yeah and and and the new york times on their mobile.

F

E

And like at tumblr on the mobile site, so it already has some some big companies using it. That's that's good. That's pretty!.

G

I didn't know the tumblr guys use this. That's good yeah! That's that's a nice little uh turnaround where we can just.

B

Go walk across the hallway and talk to the.

G

B

Guys and say: oh yeah, cool yeah marco commented he's like yeah he'd like to see it in hy.

D

Core, so I do have a gallery module that I wrote yesterday that kind of like um does this like if you pull in the gallery event hammer module you get this today, but um so it's out there. It's primarily a way for me to test this stuff, but I wouldn't encourage anyone to use it for, like anything serious, because it's just a kind of a playground for me to test this out um and it changes a lot like the it's already out of date, because I did a lot of work last night.

D

So um but it's out there if anyone wants to play around with it- and you can see it on my github- it's called gallery event hammer. So I was going to ask you like how people can get this right now. They'll just go to that library, yeah yeah! So if you go to telometra and you'll, see it there's like a there's like a yui hammer, repo and you'll find it in there.

C

So should they be able to file bugs against uh that uh like on the repo or if people want to try it out, they're like so like alpha right now that yeah.

D

It's so alpha, don't even file a bug because, like it's probably out of date like when you use it, it's not even it's not even like it's not even like the probably the best way to use. It is actually just to take the js file in there and hot link it with like raw github and use that, because, like that, that's the most up-to-date version.

D

There's still a lot of examples right that you can't go to like the. I do, have a read me, so you can check out the readme, but actually the readme is also out of date, because I added a bunch of news.

D

We should wait like a week or so right now, yeah. You just give me like you, give me like this week and then it'll it'll become clearer, also because this change has a bunch of changes in like the node module again like set gesture options, get gesture options etc. So I got to push that stuff out too.

B

There any like deeper things under the hood that this might affect like, or is it event, event isolated enough that it's just affecting event.

D

Well, it's gonna, it's gonna affect only event, but what I'm testing now is to make sure all the like weird and like all the weird things that event does under the hood are, is like what people expect. Yui events to do under the hood are still maintained, so kind of give york like an example like, if he's new, since he's new to yui, when you get a when you have an event, call back the event, facade object is that yui gives you back is different from the hammer.js event.

D

Object that you get back so in hammerjs. You have like the gesture, the you have like a source event, property and then the source event. Property has the actual event get real event thing inside it right.

D

What happens is um basically that source event is the real thing, and then we have something called like an origin event which would be which would have the hammer js thing inside it. So I have to do some like event. Facade normalization basically like to move these properties around so that yeah in yui people are exp people just like calling like e dot prevent default, and that would basically do e dot gesture dot, prevent default in hammer js line.

D

So um so I got to make sure that those things that people expect yui events to do under the hood are still apply. uh That's something I haven't done yet and then, like you, saw that little bug that I had with like the on and after stuff. I gotta fix that too yeah.

B

D

So all that sort of stuff- that's what's really left so.

B

The api for hammer js is stable, it's not any any danger of changing anytime soon. You know it's. It says two years old, but I don't know if you're planning on doing any api.

E

No, I'm not planning on doing like major api updates, and if I'm going to do that, that's then it will be in a in a minor release. So it won't be an a a a breaking change, but I don't have any plans to like add extra api uh stuff, because it's it's now is just as simple and that's like a a a really good good thing about it, because it doesn't have all the all the on on unnecessary extras.

E

F

Know if that answers your question.

B

So tila, if you, if you were, if you're, looking like how much code we're going to remove, is there like a lot or like like? What's the benefit like there's going to be a smaller code base.

D

Or notion, I think I think, there's we would probably deprecate event tap. We would deprecate event move, we would deprecate event flick and we would.

D

I think that that would be it unless I'm missing one might be missing one I forget, but those ones will be primarily, which I think and they have equivalents in the hammer. Js world flick would change the swipe, uh but but but that was that would be it and in return you get a richer set of properties.

D

You gotta um get you get um like sugar events, so you can go like swipe, left, swipe right, right, up, swipe down et cetera, which are really nice um and you get a whole bunch of new events, so that would be really nice and they all have the same payload. So you can expect to have like the same. uh You know you can you can expect those properties to be there for every event and you're saying that there's going to be.

B

A breaking change like a non-backwards compatibility change after you deprecate whatever.

D

um Yeah so like so they'll still be there and you can still use them because it's not like using hammer will suddenly interfere with your ability to use something, maybe tap, maybe tap will be messed up because hammer has a tap and we have a tab. So it would be weird, I think, like something that you probably don't want to use together, but it's not like the code would be weird um something like flick.

D

One of the things that would change is, for example, like, like I said, in hammer js, you have this set gesture options thing that I'm doing you set options on the node. You tell it. I want the node to accept gestures and behave in this way. Currently we do it on per subscription, so you say you know, on flick. Click with like this sort of velocity, so that'll, it's kind of just a change in like how you program that stuff right. But it's not really a major breaking change because we're just deprecating the modules.

I

B

So if someone had a gallery component on events right now, they might need to update at some point right.

D

Yeah and whenever I do get this in, I mean definitely something we want to rc first, but whenever we do get this in there, there will I'll definitely write up a migration pack, I'll just say: okay, if you're using flick of right now with these types of properties, then this is what you actually should be using use like swipe with this with this option or something like that, um so I'll definitely have a migration path for people like that.

B

Yeah and plus, I think don't deprecations- might need to be voted on or something like.

A

That I think you're still in beta right the gestures. So I think that that's yeah yeah.

G

I

Cool, oh so it's.

A

Not so it's not a point where it's a sixth api, it can still change. That's.

D

Cool, but you could imagine something like scroll view, which currently relies on gesture moves under the hood. We might need to go in and update that to use like you know, swipe and drag under the hood, and it would actually make a better implementation. I feel because you can do like swipe left swipe right, drag up, drag down. Do these things it would just be. It would just be easier than you'd remove a lot of code from scroll view.

D

A

D

So the net benefit's really good.

G

Then, for all of us.

D

Yeah and in terms of actual um you know, bite size like I said, hammer is two or three kb.

D

I would say that overall, we might, you might if anything like we're, actually become out, even because we remove as much code as we add in or we might be, like you know, half a kb over I don't know, I haven't, checked the details, but it's very minor compared to all the and remember like we only had three events. Initially, we were getting like 12. So in terms of kp, you actually probably save.

B

Right because you're gaining so much more features than yeah plus the other thing is, I mean just you know just another. Another aspect of this is just maintainability, like you know, hammers being actively maintained versus, like the vet system may or may not. Have someone look at it at this.

D

Point yeah, and actually you bring up a good point, which another thing that I really like that hammer does is: if you want to create new gesture events, the way you do that in hammer is very, very easy, basically like.

D

If you look at the source code, all the gesture events are defined in their own files and they have basically all have a a handler and inside the handler you basically say: okay, if these conditions are met fire this gesture, if they're not met, then don't fire the gesture um and that's a lot simpler than what we'd have to do in y ui language. You have to like define this new gesture event. We have to say, okay on listener, do this detach listen to this detach delegate. Listen to that.

D

So in this way, if someone wants to create a new gesture event- like let's say they want to click, do like on a triple tap or something you just create use the hammer way of doing it and you just pull it in and and it would be a lot simpler than going through the. Why white synthetic event space necessarily do something like that, and the benefit is like you know, you can send a pull request to hammer possibly and it would it might get pulled into court.

D

I don't know it depends on how good of a gesture.

F

B

Well, I'm really glad that you were able to come to our as well and terry you're. There do you have any questions.

B

Sorry I jerry jerry joined the the hangout. I was going to see if he had any questions. He's kind of.

G

B

No, nothing, okay, okay, cool all right! Well, thanks everybody for coming today, and thanks.

D

A lot for uh coming and I'll uh talk to you on, uh I guess github or twitter george yeah. What time of day is it? What sorry.

F

D

F

E

Well, it's now uh 15 4 4 uh noon for 12., so I'm I'm going to to to.

F

Bed now, because it's pretty late and I'm dedication coming online with midnight- yes.

B

All right all right! Well, thank you good. Thank you. Thanks to you, I look forward to seeing uh what you come up with thanks I'll talk to you guys later all right see y'all next week.

B