Skip to content
This repository has been archived by the owner on Sep 8, 2020. It is now read-only.

Need New Maintainer! #82

Closed
ProLoser opened this issue Sep 16, 2013 · 23 comments
Closed

Need New Maintainer! #82

ProLoser opened this issue Sep 16, 2013 · 23 comments

Comments

@ProLoser
Copy link
Member

So this project has gotten a bit ahead of me and the complexity has caused way more issues than I'd like to have originally dealt with. That said, want to know if anyone would like to join the project as this repo's official maintainer?

@kadamwhite
Copy link
Contributor

I can't commit to being an official maintainer, but I've got about five PR's lined up so I'd be happy to take over for an interim. Would you be open to chatting some time about the history of the project?

@ProLoser
Copy link
Member Author

@kadamwhite what specifically did you want to learn?

@ProLoser
Copy link
Member Author

@kadamwhite I added you to the ui team. Go crazy.

@kadamwhite
Copy link
Contributor

Thanks @ProLoser. My question boils down to this:

the complexity has caused way more issues than I'd like to have originally dealt with

Elaborate on the complexity?

@ProLoser
Copy link
Member Author

So I think @boneskull once said he was going to rewrite this module and I was like "Awesome! Just make sure it does x and y and z and a and b and c and d ..." to which he was like... "Yeah... nevermind" heh.

So this directive is tricky because it's VERY async. There are a bunch of async 'points of entry'.

  • When the template renders, to prevent the plugin from creating DOM and disrupting the template, the setup function is deferred. All other async behaviors (option-changes) can't execute until this one has.
  • The list of available choices may come in late (async) instead of when the page loads
  • The options may come in late (going from plugin defaults to your app defaults to ajax-loaded defaults, or just watching options for changes)
  • The default or preselected value may come in late
  • The value may be changed programmatically (by updating the model)
  • The value may be changed via interaction (by clicking on select2)

Keep in mind that since ANY of these can come in at ANY order, it makes things complicated. For example, lets say the page loads with the default or initial value, which is an id, or multiple, but you don't have the list of choices. This was in fact why I personally added the initSelection feature to select2.

There are also issues around what format the data you're working with should be in. For instance, we could work with simple string ids, and when multiple is enabled, you have 1 string with a comma-separated list. But when you're working with richer information, you may have entire objects (and not just the id property) or an array of objects. So things get confusing because you're trying to figure out if / when to have a string id, an object, a string of comma-separated ids, an array of string ids, an array of objects, etc.

This is also slightly further complicated by how select2 handles values. For instance, with <select multiple> you would more likely be dealing with an actual array, however in some scenarios, this is not what select2 does. He uses an <input type=hidden> when he expects you to programmatically add options (instead of changing the <option> list). Now, this is actually a GOOD design point, because it means if you load 400 options, we don't have to keep the DOM in sync, and improves performance. But the catch is that <input> doesn't natively handle arrays. Also, I didn't know about ng-list when I was building this directive.

There's also issues when setting the value programmatically. When you work with an array of rich objects, and someone sets the value using a string id, do we immediately look it up and convert it to an object? Do we expect people to set it to an array of string ids? Do we force people to always have full objects?

So at any given time there's such an exponential number of issues I'm dealing with that it makes things difficult to fix. For instance, we COULD just say you're ALWAYS supposed to use <select> and update the ng-options yourself, but now you can't use templating and your values are always string ids instead of rich objects.

It's part of why I believe TwitterBootstrap dropped typeahead and made it it's own component, because they were learning more and more just how complex of an issue this really is.

I think the best solution is to just trash this plugin and rebuild it natively in AngularJS and just support the same DOM and CSS as the original (or bootstrap). But this would mean lots of work to support things like supporting keyboard commands, resizing the input box as needed, and creating those little tag widgets (for multiple select).

If you're interested in that endeavor (and it would be something I could actually HELP with) assuming we design something that can be leveraged by the @angular-ui/bootstrap guys and lots of other people, we could create a new ui-select repo and slowly phase this one out.

@ProLoser
Copy link
Member Author

I spent 15 minutes prototyping this: https://github.com/angular-ui/ui-select

@dimirc
Copy link

dimirc commented Nov 4, 2013

@ProLoser I was about to start a directive as a wrapper for another similar library https://github.com/brianreavis/selectize.js using your current directive as example.

But after reading your last comments, I'm hesitate to start it and maybe spend some time on creating a native one. BTW, have you ever checked selectize library?

@ProLoser
Copy link
Member Author

ProLoser commented Nov 4, 2013

@dimirc yeah that looks pretty much identical to select2. Pretty though. Anyway, yes, if you want to do something useful, I HIGHLY recommend NOT simply wrapping ANOTHER third-party lib. If you're interested I can add you as a collaborator to ui-select and would be much better poised to provide advisory feedback in that situation.

@dimirc
Copy link

dimirc commented Nov 4, 2013

@ProLoser I need this functionality for a current project, so I'll need to do it and will be glad to contribute. I was thinking about checking other native directives like https://github.com/angular-ui/bootstrap/blob/master/src/typeahead/typeahead.js to take some ideas. Let me know any advices.

@vitalets
Copy link

vitalets commented Nov 5, 2013

Yes, guys, did you consider improving typeahead.js for functionality like select2 ?

@ProLoser
Copy link
Member Author

ProLoser commented Nov 5, 2013

@vitalets if you're talking about the ui-bootstrap file, there's just soo much wrong with that. But the TL;DR version is that ui-select can and should use typehead as an approximate starting point.

@vitalets
Copy link

vitalets commented Nov 5, 2013

@ProLoser I mean maybe not take whole ui-bootstrap.js, just take typeahead.js and improve it ?

@dimirc
Copy link

dimirc commented Nov 6, 2013

@ProLoser @vitalets I created an issue to better discuss about typeahead.js and this new directive

@pkozlowski-opensource
Copy link
Member

@ProLoser could you elaborate on:

if you're talking about the ui-bootstrap file, there's just soo much wrong with that

@ProLoser
Copy link
Member Author

ProLoser commented Nov 7, 2013

@pkozlowski-opensource bottom line is I think it's the wrong direction. I don't like this obsession with bootstrap. I think we should make a FRAMEWORK-AGNOSTIC solution, and simply provide customizations, presets, skins, templates, etc that make it function IN bootstrap. But it shouldn't be based off of bootstrap, which is a FAR more basic implementation than Select2, a project I personally have collaborated on since before AngularUI was even founded.

I have briefly discussed with people the idea of using directive layering and extending to create framework-agnostic base-solutions that you could then customize to make them compatible with framework templates.

@shaungrady
Copy link

I agree with what you're saying @ProLoser. Directive layering sounds like it has the potential to be an elegant compromise.

@BaconSoap
Copy link
Contributor

Is there a new maintainer that is going to actively support this again? If not, what is the process to become a new maintainer? We use select2 and angular extensively in our project, and we don't want to be locked to older versions of the libraries. We were looking to get the official repo updated instead of creating another out-of-sync fork.

@ProLoser
Copy link
Member Author

I'm open to anyone who would like to volunteer as new maintainer.

On Mon, Dec 16, 2013 at 9:06 AM, Andrew Varnerin
[email protected]:

Is there a new maintainer that is going to actively support this again? If
not, what is the process to become a new maintainer? We use select2 and
angular extensively in our project, and we don't want to be locked to older
versions of the libraries. We were looking to get the official repo updated
instead of creating another out-of-sync fork.


Reply to this email directly or view it on GitHubhttps://github.com//issues/82#issuecomment-30678617
.

Dean J Sofer
[email protected]

BS Computer Information Systems
California State Polytechnic University, Pomona
Telephone: 714-900-2254
Website: www.DeanSofer.com
Github: github.com/ProLoser

@BaconSoap
Copy link
Contributor

I would definitely volunteer to do it - we're working internally to keep up to date with angular and select2 since we're locked in, and I've been doing work manually merging some of the pull requests on my fork to get it back up to speed so we can upgrade (right now it's locking us at angular 1.1.4).

@ProLoser
Copy link
Member Author

@BaconSoap have at it!

@BaconSoap
Copy link
Contributor

Thanks! I'll be re-reading back to this ticket to keep in mind the issues you raised a few comments ago - they are challenging but I think good to address, especially the framework-agnostic layered directives idea.

@ProLoser
Copy link
Member Author

@BaconSoap if you're interested in that check out the https://github.com/angular-ui/ui-select repo. I wouldn't really bother tackling 'framework agnosticism' in this project as it's already closely tied to both jQuery and a third-party lib.

@vitalets
Copy link

Good news! thanks @BaconSoap!!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants