-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API consistency. Use item instead of text everywhere #16821
Comments
+1 On Thu, Jan 21, 2016, 15:17 Vladislav Zarakovsky [email protected]
|
Idea: How about we pass an object that has properties with all the stuff we need, and a |
Do you mean wrap replace: function (item) {
this.input.value = item.toString();
} Need to think more on this. It might work for But we still have old $.fire(this.input, "awesomplete-select", {
text: selected.textContent,
item: this._list[this.index] |
You don't need to explicitly call |
Oh, actually, nevermind. I just read this more carefully. Yes, we should have both item and text, for backwards compat. |
Great! So we have We have Looks like you agree to use @LeaVerou Which leaves only 1 more requested property without chosen name - the selected LI element. I propose to use // already names properties
text: itemText,
item: itemTextOrItemObject,
origin: clickedChildOfItemElement
// NEED TO NAME THIS ONE!
element: selectedItemElement, // or maybe `selected` (but to me `origin` aligns better with `element`) |
Why can't this be the event target? |
Event target for |
Oh right. It's been a while! |
The I've come up with I'm experimenting with |
Something like this:
This is just to get an idea of how it can be implemented. |
Wait, isn't item and element the same thing? What's their difference? If I'm that confused, I'm worried our users will be way more confused... |
Well, this is what all issue about. We need good names. As we discussed already both item data ( Or do you referring to my idea in this commit? vlazar@a18f32b#diff-0861bfe5a8e20a86e84f647fe9e26358R143 I don't like |
We can use With Event properties: // existing property, selected text (does not work for objects)
text: itemText,
// existing property, exact clicked DOM element
// can be a child of LI if clicked with mouse or LI when selected with keyboard
origin: clickedChildOfItemElement
// new property
// string, if list was initialized with array of strings
// object, if list was initialized with array of objects instead of strings
// example: { id: 1, title: "JavaScript" }
item: itemTextOrItemObject,
// new property
// selected LI element
// Personally I don't think it's very useful, especially with existing origin property
// and if we add item property mentioned above. It's just that others requested it
// and there is no element.closest() in IE to get it with origin.closest("LI")
li: selectedItemElement Instance properties: // note: item name already taken for render item function
// use select prefix to align with other similar properties
get selectedItem() {
return this._evaluatedList[this.index];
},
get selectedLi() {
return this.ul.children[this.index];
}, |
One more combination on names. Event properties: text: itemText,
value: itemTextOrItemObject,
origin: clickedChildOfItemElement
element: selectedItemElement Instance properties: get value() {
return this._evaluatedList[this.index];
},
get element() {
return this.ul.children[this.index];
}, |
OK. Smaller changes are easier to follow. Here is what it roughly takes to pass item data instead of just text everywhere: vlazar@b7adf40 Later we can also add getter. |
One more idea. If data required for events are also available as instance property we can add just one property - $.bind(input, { "awesomplete-select": function (evt) {
// Awesomplete instance
evt.instance;
// selected LI element
evt.instance.ul.children[evt.instance.index];
// or with getter
evt.instance.element;
// selected data object
evt.instance.suggestions[evt.instance.index];
// or with getter
evt.instance.value;
}); |
Ok, I see now. How about: text -> text ? Definitely not |
Not sure about Was only selected |
Oh, I didn't even remember there was a de facto standard about it, I was just suggesting it as our own property :) |
I can change I'll start adding get data() {
return this._evaluatedList[this.index];
},
get element() {
return this.ul.children[this.index];
}, |
Here is the PR for item data property #16835 Please consider addition of related instance property as well. And if the name |
Yes, definitely. I propose |
I assume I have to know logins to unsubscribe even if that was an option. Any value prop of github and your project was immediately lost with the automatic transmission of every message since the dawn of man Thank you,
|
Github is just the site hosting my project, I do not control what they do with email notifications, nor did I make the site. I’m just trying to be helpful here. You (well, more likely someone with access to your email) subscribed to this project, which is why you're getting the notifications. The username I see is Sundevil96 and their photo is this one if it rings any bells. Perhaps your son or partner? You can try clicking "forgot your password?" on the login page, so that you can reset the password via email. And seriously, don't let other people use your email to avoid such problems in the future. :) |
So how we fix it? Just allow to override any read only property on Event? $.fire = function(target, type, properties) {
evt.initEvent(type, true, true);
for (var j in properties) {
- evt[j] = properties[j];
+ Object.defineProperty(evt, j, {
+ value: properties[j],
+ configurable: true, writable: true, enumerable: true
+ });
}
return target.dispatchEvent(evt);
}; I haven't tested all read only Event properties, but overriding at least We can at least special case + if (j == "cancelable" || j == "bubbles") continue;
Object.defineProperty(evt, j, { |
You can try setting and defineProperty if it fails. Otherwise even if an accessor has a getter, you're not using it (case in point with cancellable and bubbles). |
Or we can just use a different name, I give up. This is too much work just to use |
Or maybe it's ok to just use |
No, it is not. |
Reverted in dfd16c9. Didn't knew there are some writable event properties. |
Thanks, and sorry for the back and forth on this. I still think that |
And we need to decide on others as well. Did I understood you correctly in my comment above? #16821 (comment) Now we have So we keep just the |
Also, if we going to provide access to Awesomplete instance from the event... maybe instead of adding this.input.awesomplete = this; If it's the only property we will add to input... then it should be fairly safe to do as it won't leak nowadays? Or do we still need an auto incremented string property on DOM element and using cache object in JS like jQuery and others do since like forever? |
My main worry is that some people tend to get a bit uncomfortable when you add properties to DOM elements, due to the old IE memory leaks (which are completely obsolete by now but the aversion remains because humans are not rational). But apart from that, that's great. I wonder if anyone else has any opinions? |
Lea, can you please also answer my previous question, while you are here? :) #16821 (comment) |
or we can use ES2015 maps 😈 |
I'm leaning towards it, but no strong opinions there. Up to you. :) |
If I understood you correctly, you are not in favor of removing |
I'm all for IE11+ :) Would make other parts much easier too. |
Ok!
Hmm. Let me think about it for a bit. |
Turns out Map/WeakMap support is not so great in other browsers too. Probably not an option in the near future. As for old IEs, we can just wait until IE10 usage drops below 2% :) |
IE10 usage is 0.81%. Same with IE9. IE8 is 1.02%. I've stopped worrying about them in my own projects, but still try to support them in libraries mainly because other people care (probably due to misinformation propagating: Either they or their bosses/clients think IE<10 is way more popular than it is. And there are of course also the huge sites that actually should care). |
WeakMap can be polyfilled (and one is available through polyfill.io), but On Fri, Feb 19, 2016, 08:59 Lea Verou [email protected] wrote:
|
What source do you use? |
Interesting. I would rather expect the opposite.It might have to do with a desire to limit the size of polyfills. One could just use WeakMap, no big need to polyfill Map too. |
caniuse, which gets its data from StatCounter.
Same here! Btw note that I'm not saying we should use Map. People do care about IE <= 10 (even though in most cases they shouldn't) and I'd rather not depend on polyfills. We could keep it in mind for the future though. |
With official support dropped in January I hope IE10 memories will die pretty soon 😈 |
Fingers crossed :) |
Continues #16818
With list of string items everything works out of the box right now.
There is also a frequently requested feature to have items as objects (key/value pairs). Making it work on top of current API is problematic.
Currently we pass list item (either a string or an object) to:
And here we have text (so items as object won't work):
I think this needs to be changed so that when we have list of objects both
replace
andawesomplete-select
would also get the whole item data instead of text only. This change would make features like key/value support much easier to implement.If we go with this, then the question is how we implement this API change.
We can make it as non breaking change in
1.x
(possibly showing deprecation warning in console too):And cleanup API in 2.0:
However in this case
replace
signature changes twice. So a better option would be to introduce newitem
instance property, which would be a selected item data (text or object) - essentiallythis._list[this.index]
. We can even havereplace: function ()
without arguments in 2.0 sincethis.item
would be accessible on any instance. So 2.0 API can be:See also related discussion #16819
The text was updated successfully, but these errors were encountered: