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

Support for overriding prop values #530

Open
elliotgeno opened this issue Feb 14, 2020 · 5 comments
Open

Support for overriding prop values #530

elliotgeno opened this issue Feb 14, 2020 · 5 comments

Comments

@elliotgeno
Copy link

Not sure if this functionality is already available, but currently, if you provide another component to an attribute, the JSX that is rendered shows the value of the object instead of the displayName. For example:
<Accordion.Toggle as={Card.Header} >
is rendered like:
<Accordion.Toggle as={{ $$typeof: Symbol(react.forward_ref), defaultProps: undefined, displayName: 'Card.Header', render: function noRefCheck() {} }} >

I would like to only show the displayName in this scenario.
Is there a way to override the string the attribute returns?

If not, maybe we can make a slight adjustment to options.filterProps to work similarly to options.displayName?
If you provide a function, and that function returns a string that isn't a boolean, use that new string for the attribute value instead.

Sound good?

@elliotgeno
Copy link
Author

In this case my filterProps object would look like this:
filterProps: (value, key) => { if (key === "style") { return false } if (key === "as") { return value.displayName; } }

@elliotgeno elliotgeno changed the title Support for overriding attribute values for displayName... Support for overriding prop values Feb 14, 2020
@dvnrsn
Copy link

dvnrsn commented Oct 19, 2020

This would be nice for really lengthy prop values as well. Say one has a long array of objects. It'd be nice to be able to render something like array or [{}, {}]

@quantizor
Copy link

quantizor commented Nov 29, 2021

@Andarist would it be possible to add this functionality? maybe mapProps instead of filterProps so we're not overloading

@Andarist
Copy link
Contributor

@probablyup note that I'm not a maintainer of this package - just fixed some issues here a few weeks back

@as-zlynn-philipps
Copy link

Thanks for your work, @probablyup. I hope it gets merged. Although, it doesn't really address the need to format prop values on the fly as an escape hatch. I believe that would still be useful.

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

No branches or pull requests

5 participants