The title says it all.
@cungminh2710 it is an API design decision. You can add styles to children (you can even have an anchor as its children)
I came across this also, a solution as described might look something like:
<Link href="/"><a className={style(styles.linkDefault)}>my link text</a></Link>
const styles = {
linkDefault: {
color: '#009900',
}
}
this is super weird.. we probably should accept className and style as props in the link component
@impronunciable what are the downsides of not accepting props like className on Link?
It seems very odd to have to pass an anchor element as a child to Link just so we can style it.
Would be super interested in having the className working with also or having a good understanding of why this is a bad idea ;-) .
My current use case is the following, i use semantic ui for my app and i can do something like that to render semantic default element as a Link for the next/router to catch the route, but this is trashing the layout cause Link doesn't set the semantic Menu className.
<Menu.Item as={Link} to='/page1' />
I do a workaround using onClick - e.preventDefault() - url.pushTo('page1') , but this is not ideal.
Thanks anyway for the great work here
@flybayer You can always style it from the parent instead of trying to pass more elements down with Link.
Having Links with classes however, seems like a common practice, specially in any of the frameworks around. A simple example, Links that show up as buttons.
I'd be interested in knowing any downsides to allowing different props to pass down to the <a>element rendered.
Most helpful comment
this is super weird.. we probably should accept className and style as props in the link component