Fundamental problem with the library

[jesprider]

There are quite a few libs out there providing similar functionality. I chose this one because:

1. It looks great.
2. It has relatively good documentation with an external website.
3. Set of features is good at first glance.

Nevertheless, when started using it I found several fundamental architectural mistakes:

1. For some reason, tags suppose to be an array of objects. Really? Why not accept a simple array of strings as well? Solution: add support for a simple array.

2. There is no simple way to adjust tags before it is added. Simple use-case: you have to prefix every tag with a hash. Solution: additional prefix/suffix property that will be added just for representation, but won't be in tags array.

3. Validation seems half baked to me. I expected to see a callback as well. Maybe I want to warn a user about something, and not adding an error class name. Solution: add additional prop callback that will be triggered when validation didn't pass.

4. When you add tab key as a trigger for adding a tag, next tab click does nothing. It should change focus to the next element in a form. Solution: check where a user clicks on tab key and react differently.

Also, I wanted to mention that markup with a list (ul > li) looks overkilling in 21 century. But it is more a matter of taste I think.

Overall the library looks overwhelmed with not necessary features and lacking basic ones (or maybe it the documentation is just a bit noisy). With a close look the documentation can be a bit "cleaner".

I hope that my arguments do make sense and I didn't miss something in the documentation. Otherwise please let me know and correct me. Hope to use the fixed version of library in the future.

[ghost]

Regarding your first point: there is a createTags helper that lets you pass in an array of Strings: http://www.vue-tags-input.com/#/api/create-tags-helper

[coreation]

Waw, you get so much code for free, all from 1 person, and you close your issue with "hope to use the fixed version of the library". Make a pull request and make your hands dirty, give the man some proper kudos, because this library isn't even broken.

[jesprider]

@coreation so your argument is that if I get it for free and from one person it can be lower quality? :) Even though it's not broken code-wise, it is broken design-wise/architecturally in my opinion. If it works for you - go ahead.

I think that the analysis that I did and the solutions I proposed is already a contribution.

This is how competition works: if your library is not good enough people will choose another one. So did I. If this would be the only library I would either write my own or open a PR.

[coreation]

Fair enough, there are a bunch of similar libraries out there, there's only 2 I found that played well with Vue and provided decent support for autocompleting where the dropdown is filled via API calls. My problem however is with your use cases you're missing in this library and then calling it broken architecturally, while none of suggestions even tough upon the architecture. Choosing between an array of string or objects, is hardly an architectural decision... design comes close ;) (1) and (2) you putting out some scenario's that are very niche while also saying it contains too many features and missing basic ones. You can't have both.

To help you out though, I think you can easily prefix your tags by either leveraging the before-add-tag event or by controlling the tags property yourself. The third option might be that you style the left spot of the tag (http://www.vue-tags-input.com/#/examples/templates)

[jesprider]

@coreation okay, I see your point. First of all, we have a different understanding of the library design/architecture definition. And let's put it away, otherwise, we both will be unhappy with the amount of time spent on this conversation ;)

Nevertheless, I'd like to express my vision on input-tags abstract library. Let's answer the question: what should be in the MVP of a library. In my opinion, it should be the following:

1. Base: adding tags by specific keys and storing them as an array of strings.
2. General: on-add event.
3. General: simple validation with a callback.
4. Accessibility: tab key should work properly.
5. Design: should be easy to re-style the input and the tags.

If we agree on that, then we can add more additional features, which shouldn't touch the base version. Meaning that if you want to convert an array of tags to objects, then only those who need it should adopt. Why should 50% (I think 80-90%) of users that need just a plain list map it to objects?

This is, in short, my way of thinking about this library.

P.S.: My goal was not to be rude or offensive but rather constructive. And I am sorry if I sounded like that. If the vision of the library is not matching mine - that's fine. But if I would be the owner of it, I would like to receive feedback like this. Otherwise, how can you make sure you're doing right/wrong things?!

[coreation]

It did come across rather negative - it came across as this was a broken library from the perspective of what it's promising to do. I'm taking a very defensive standpoint here because this library saved me a buttload of time - so i'm interested in what other libraries you found ;)

1. If there's no specific reason to use objects, strings make more sense, but I can imagine using objects to store for example a display name and an actual value. Which would solve your problem with the "#" right away, without having to strip the "#" when saving them somewhere for example.
2. did you have a look at the current hooks? I'm not sure where in the lifecycle of adding a tag you mean to throw the on-add event and what the result must be, but i think this library already has 1 or 2 events thrown when adding events.
3. +1
4. nice to have in my perspective
5. they are quite easy to restyle, i'm really not a JS/CSS magician, and managed to do some styling even beyond what the documentation provides as CSS properties to re-use. Is that not easy enough or do you expect easier integration with styling sheets?

+1 for constructiveness.

[jesprider]

Again, the library does things and it has many good features. I'm raising a question of how the library does it. And it's not optimal IMHO. I could have satisfied all my requirements with this library. And I almost did it, but with each step, I felt that it's doing it wrong. @lfridael mentioned create-tags-helper, you mentioned templates for simple things. I'm glad that for your specific use case you saved a lot of time, but those simple things should be done intuitively, ideally without documentation :)

[coreation]

For a more stripped down version, without an easy to use AJAX driven dropdown, you might want to checkout this one: https://sean.is/poppin/tags I've used it before I had to implement a dropdown filled with results from an API call. Taggle.js supports it, but in a way that feels really low level, and my goal isn't to go as low level as possible, but speed ;)

[jesprider]

Thanks. I'm already using https://github.com/matiastucci/vue-input-tag and I found it perfect for my use case. I copied the code, adjusted it and using now as an internal component. Also, this approach saved me several kb I guess. Anyways, nice to see that this library works well for particular use cases.

[bertog]

Thanks. I'm already using https://github.com/matiastucci/vue-input-tag and I found it perfect for my use case. I copied the code, adjusted it and using now as an internal component. Also, this approach saved me several kb I guess. Anyways, nice to see that this library works well for particular use cases.

Thanks for the suggestion of this alternative package, working like a charm also for me. I think this package could be incredibly powerful, but maybe a better documentation could help for normal cases like save/retrieve data from a db, without digging in the issues ...