Skip to content
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

Allow providing custom attributes to <Tab> (spread attributes) #93

Closed
wants to merge 2 commits into from
Closed

Allow providing custom attributes to <Tab> (spread attributes) #93

wants to merge 2 commits into from

Conversation

MartijnHols
Copy link

@MartijnHols MartijnHols commented Apr 19, 2016

This PR makes it possible to provide custom attributes to <Tab> through attribute spreading on the rendered <li> component. This allows both overriding of the existing attributes (except className) and to provide new attributes as shown in the tests.

This solves my wish to be able to set "data-tip" for tooltips with react-tooltip, and resolves PR #92 and issue #44

Edit: would also provide a solution for #97
Edit2: Oops, didn't know a PR would automatically update with new commits, moved the commits not related to this PR to a different branch and force reset master, PR should be ok now.

danez pushed a commit that referenced this pull request Jun 11, 2016
@danez
Copy link
Collaborator

danez commented Jun 11, 2016

Thanks I merged your PR. I also added this feature to all the other components as well.

The only thing i changed is the overwriting behavior, to not allow anything to be overwritten, as currently the tabs depend on some stuff being set in DOM, and I don't want people to be able to break the tabs mistakenly. Relying on DOM stuff is anyway not a good idea so maybe in future this can be changed.

Hope this is okay with you, I also left your name in the commit.

via a387f9d

@danez danez closed this Jun 11, 2016
@MartijnHols
Copy link
Author

Thanks!

I never weighed the two options of overwriting or not overwriting attributes against each other. Just figured being able to overwrite library behavior in case it's conflicting with my needs was handy. I realize this is usually only done as a workaround for issues in a library itself, but considering it's hard to imagine all possible use-cases it might still be right to do. I guess someone can make a new issue/PR if they ever really need this though.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants