Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
RFC: react component HOCs allowing for bringing your own component
See original GitHub issueDo you want to request a feature or report a bug?
feature
current behavior
The current set of react components bring their own, strongly opinionated DOM.
Example:
<Authenticator />
brings it’s own specific versions of <AmplifyUI.InputRow /> , <AmplifyUI.FormRow />, etc, and each of those brings an explicit <html> element of its own choosing.
This is problematic because it hinders extension. For instance, what if you need to use your own component library’s visual components, whilst still getting the benefit of the amplify HOC? Consider if your component library has deep prebaked CSS styles & JS bindings on something as simple as an <Input />. you may care to use said <Input />, but instead must use the <input /> that <AmplifyUI.InputRow />owns completely, and style it through the theme interface. The theme interface is a great start, but adds complication when really all you want out of the library is the logic and perhaps component structure, not the aesthetics or DOM.
expected behavior
luckily, this is a solved problem in other react spaces. there are two implementations that i use commonly, and thus cite both for reference
- react-styleguidist
- essentially, they let you create a map between their internal HOC’s and your own components. your own components just need to render children and pass thru key top-level props
here’s a hypothetical usage:
// some amplify aware file
const theme = {
...,
components: {
FormRow: MyCustomFormRow,
InputRow: MyCustomInputRow
}
}
// AmplifyUI.jsx
...
export const FormRow = (props) => {
const theme = props.theme || AmplifyTheme;
const style = propStyle(props, theme.formRow);
const p = JS.objectLessAttributes(props, 'theme');
const ElementType = getElementType('FormRow', theme) // returns MyCustomFormRow if provided, or, the previous default, `'div'`
return beforeAfter(
<ElementType {...p} className={themedClassName("amplify-form-row", theme.formRow)} style={style}>
{props.children}
</ElementType>
)
}
- semantic-ui-react, aka SUIR
- SUIR lets you use any of their components with an
asprop. - e.g.
<Header as={SomeOtherComponent />, vs. the default<h1 />, etc
- SUIR lets you use any of their components with an
The SUIR strategy works best when composing components from the bottom up. The styleguidist approach works best when users want to use a predefined component structure, but with tweaks to the DOM tree. Most likely, a styleguidst approach would be the ideal 1st pass, with consideration for using the SUIR approach longer term.
I’d be happy to PR this if accepted.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Hi @cdaringe,
Thank you for the suggestion. We do accept PRs, and I have added this to our backlog too.
This issue has been automatically locked since there hasn’t been any recent activity after it was closed. Please open a new issue for related bugs.
Looking for a help forum? We recommend joining the Amplify Community Discord server
*-helpchannels or Discussions for those types of questions.