Adds tag creator

[flovilmart]

Adds allowCreate=true prop so the field will allow option creation.
By default this option is disable to maintain backward compatibility

[dcousens]

Hi @flovilmart, could you please update this PR without the dist files? (and rebase if necessary)
I think this is a cool addition in any case :)

[flovilmart]

Ok. I'll do my best :)

On Mon, May 11, 2015 at 8:47 PM, Daniel Cousens notifications@github.com
wrote:

Hi @flovilmart, could you please update this PR without the dist files?

I think this is a cool addition in any case :)

Reply to this email directly or view it on GitHub:
#151 (comment)

[flovilmart]

Rebased and removed the commits from the dist and lib

[bsr203]

+1

[beeant]

+1

[flovilmart]

I've updated, and rebased

On Wed, May 13, 2015 at 1:37 PM, Bryant Teja notifications@github.com
wrote:

+1

Reply to this email directly or view it on GitHub:
#151 (comment)

[dcousens]

Thanks @flovilmart this is great.

[dcousens]

@flovilmart should a callback be fired to notify of a new tag? We should probably try to lift more state out of this component.

[flovilmart]

Not that implémentation, just the on change is fired. That would be a nice feature (but I didn't need it at the time)

On Mon, May 18, 2015 at 2:53 AM, Daniel Cousens notifications@github.com
wrote:

@flovilmart should a callback be fired to notify of a new tag?

Reply to this email directly or view it on GitHub:
#151 (comment)

[dcousens]

@flovilmart thoughts about making a PR for it? :)

[flovilmart]

Haha :) you could do it too :p what callback signature would you like? 

Would you want if before or after the change?

Do you want it cancellable?

On Mon, May 18, 2015 at 7:18 PM, Daniel Cousens notifications@github.com
wrote:

@flovilmart thoughts about making a PR for it? :)

Reply to this email directly or view it on GitHub:
#151 (comment)

[dcousens]

@flovilmart haha, before the state change is always better, that way the user can throw new props at it if necessary.

Do you want it cancellable?

That is a good question, if this module was structured properly, we'd handle this like an onChange event for a typical field and manage the state in the parent, but, at least right now, the state is being managed internally... :(

[flovilmart]

As for thé signature, I could go with the same as onChange.

Call it onAdd?

On Mon, May 18, 2015 at 7:46 PM, Daniel Cousens notifications@github.com
wrote:

@flovilmart haha, before the state change is always better, that way the user can throw new props at it if necessary.

Do you want it cancellable?

That is a good question, if it was structured properly, we'd handle this like an onChange event for a typical field and manage the state in the parent, but in this case, the state is being managed internally...

Reply to this email directly or view it on GitHub:
#151 (comment)

[dcousens]

@flovilmart sounds good to me

[flovilmart]

Just created another PR, maybe we should rename allowCreate to enableAdd, or canAdd or allowAdd, or addEnabled...

[dcousens]

canAdd works for me.

[nickbouton]

+1