Is this project still being maintained?

[cdjackson]

Activity from the maintainers seems very low and there are hundreds of PRs and issues.

Is this project still being maintained, or can someone suggest an alternative?

[wald-tq]

I think this project is the best bet for a angular native implementation of a select2 field.

There have to be many developers which are using this directive and they know the way around the hard edges (including me).

Another alternative could be Angular Material with the nice chips: https://material.angularjs.org/HEAD/#/demo/material.components.chips

[cdjackson]

Thanks. I agree - this is still a good project, I'm just concerned that it's not really being maintained and therefor it will quite soon become not such a good project :(

There have to be many developers which are using this directive and they know the way around the hard edges (including me).

This is what concerns me :) I'm also making some modifications and have submitted a few PRs over the past few months, but there are now around 150 open PRs, and 470 or so open issues. It would be great if the maintainers no longer have the time to support it if others were able to...

The longer PRs are left unprocessed, the more difficult it is to merge them as there will be conflicts...

[wald-tq]

I'm also a bit concerned. I use it throughout my project and I don't have a better choice for now.

Also see this discussion: #1096

[ProLoser]

Are either of you interested in taking this project over?

[sars]

@ProLoser , I'm interested also in development this project. Ready to help

[dimirc]

@sars one way to help could be to try checking duplicated issues and posible PRs

[cdjackson]

Are either of you interested in taking this project over?

I would be happy to help with the project. I think since this is such a popular project that it needs a few people to help maintain it as it needs to be regularly maintained. Currently, we go for months without any activity from the maintainers, and hence we end up with a totally unmanageable number of PRs and Issues... I don't mean to criticise, people have a lot of demands on time these days, but the project can't thrive if nothing changes for months on end...

I'm not currently hugely familiar with the source, but would be willing to help maintain it. I would be happy to initially spend a few days going over the issues found in #1096. From there I would suggest it might be easier to close "all" old issues (say, older than 4 months) - or at least request that it is still valid. Likewise for PRs - many already have conflicts and need to be updated against the last codebase. This could allow the project to be brought back into a manageable situation where a few people should be able to keep on top of things every day or three (and I would be happy to support this too)...

Just my 2p :) Maybe the above suggestion is a little drastic, but this is a nice project, and I think it needs something to bring it up to date...

[ProLoser]

@cdjackson That's fine.

[dimirc]

@cdjackson agree also

[cdjackson]

Just an update on what I'm doing. I've removed a lot of watches which i don't think are necessary, and are probably bogging down the digest cycle. I've completely removed tagging and refresh from the core and have added lifecycle handlers (currently onKeypress, onBeforeRemove, onBeforeSelect and onBeforeDropdown) which should allow tagging and refresh to be implemented externally - or various other forms of the control.

The reason I picked on tagging as a starting point is it is spread throughout the control and it made the code a bit messy (IMHO!). Possibly the onKeypress() callback doesn't allow as rich a tagging implementation (I've not spent too much time testing this), but it is ok, and these callbacks ought to allow better implementations than my quick test tagging implementation. I've also used this to create a combo-box control, which allows you to select from the list, or type in whatever you like, and this ought to be possible with these callbacks.

I've also updated the build to produce separate implementations for the different templates (the templates account for ~10k), and separated out the sort directive... It's still work in progress, but thought I'd mention what I was doing... If it's outside of what is required for this repo, then at least I'll be in a position to make my combo-box control :)

A rough estimate of size reduction (comparing to minified versions)-:
Original ~35k
Remove tagging ~31k
Remove refresh ~30k
Remove templates ~25k with just a single theme

The sort directive is about 1k as well... I've also fixed a few bugs along the way...

This is clearly a significant (and breaking!) change to the current repo (well, if you are using tagging or refresh anyway!), so I'm not sure if it's of interest or not. If it is, I'm happy to tidy, sort out the tests and provide it for review - otherwise I'll just stick with this in my projects :)

[ProLoser]

You should open a pull request so we can start providing feedback (although I expect it to be nearly unrecognizable lol). Alternatively, perhaps we should give you push rights and let you work on a branch on this repo so that we can keep this a collaborative effort and other people might be poised to support your endeavors.

One thing I'd like to see is that we still (to some degree) implement some of the most critical prior features, but doing so in this composeable approach. For instance, demoing how tagging or custom entries would be done with this new API will help other devs further rip out core code.

[ProLoser]

What is refresh btw? And what sorts of watchers have been removed? If these are things that can be converted to JIT (Just In Time) evaluations, that's always better. It's not like you need to keep the settings up to date while you are NOT interacting with it, and it's not like it's a reasonable expectation for the widget to update while you ARE in the middle of interacting (or if this is the case, allow people to do this themselves).

[cdjackson]

although I expect it to be nearly unrecognizable

Maybe not unrecognizable, but certainly a diff will tell you (I think) that every line has changed as I've reformatted, added more comments, and fixed a few bits of code...

perhaps we should give you push rights and let you work on a branch

That's also fine - I'm not sure that you can limit access to a branch, but I can play nicely :)

One thing I'd like to see is that we still (to some degree) implement some of the most critical prior features

I agree - I have re-implemented tagging (in a basic sense!) for exactly this reason (and I intend to use it!). Currently, it probably doesn't support a bunch of features, but using the onKeypress, it should be possible to do most/all of what the current binding does. For example, tagging works fine (from my basic tests) but I only support enter to end tagging, not a list of tokens, but this should be easy to implement.

Additionally, I have the combo style, which uses the single select to add custom entries - maybe the control already did this, but I couldn't see how and the docs weren't forthcoming...

Both of these are working in a demo form (bootstrap only) that's included in my test branch (newdemo.html/js).

What is refresh btw?

It is/was an async loading callback. I didn't look at the implementation in detail, but it called a user specified method when the control was opened, and then called it again every user defined seconds. I've not tried to implement this in my demo, but it shouldn't be hard - I've added a callback for the dropdown opening and closing, so the user can start/stop a timer to do whatever async stuff they like!

And what sorts of watchers have been removed

Many of the watches/observes on configuration options - it's possible I might have gone too far, but things like searchEnabled, sortable, all the tagging options (tokens, label etc) were watched but these have been removed now anyway. Relevant options like the searchEnabled could be added back into a method that re-evaluates on dropdown if someone really thinks they need to be changed dynamically - this would be simple... I'm sure someone will tell me there's a use case, but I was in a slightly ruthless mood :)

The way things are at the moment is I've not added extra API methods for manipulating the control within the callbacks. I'm split between adding specific public API methods and potentially reducing flexibility, or just allowing interaction directly with the controller. I'm happy to take 'angular-ui' standard practice/guidance if there is any on how you'd prefer to see this...

Currently my mods are in https://github.com/cdjackson/ui-select/tree/refactor_branch

[ProLoser]

@cdjackson will need some place to provide feedback on your branch.

Few notes, I was poking around your addons, you are not making of this controller methods. The first and foremost priority is to expose EVERYTHING as a controller method. This allows you to inject the directive-controller and override the methods (making onWhatever callbacks a redundant convenience tool).

I don't remember what the lookup MAP is for, but I don't really know if we should bother with it anymore. If we use the mapped keys explicitly in our code, that's fine, but if we're trying to expose some sort of convenience to users, it should be removed. Let devs sort out keycode aliasing themselves.

Refresh is stupid and should be removed. Instead, simplify and expose the collection of items we use to render the dropdown. This will allow users to hack this list at any time they want with whatever they want. This feature definitely does not belong in the core.

Again, please RELIGIOUSLY pore over this new directive I assembled (and the README examples) for guidelines on what I'd like to see: https://github.com/angular-ui/ui-mention/blob/master/src/mention.es6.js

I agree with removing all these silly watchers. We can simply set boolean flags on the uiSelect controller that are checked whenever the control is interacted with.