Is it a good idea to put all className classes as a prop in react?
I'm just wondering is putting your className
classes inside the prop in React class? Here is my code so far.
var app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header navbar="navbar fixed-top navbar-custom"/>
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
return(
<header>
<div class={this.props.navbar}>
<a href="#" class="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
Thanks for the constructive advice.
javascript html css reactjs
add a comment |
I'm just wondering is putting your className
classes inside the prop in React class? Here is my code so far.
var app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header navbar="navbar fixed-top navbar-custom"/>
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
return(
<header>
<div class={this.props.navbar}>
<a href="#" class="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
Thanks for the constructive advice.
javascript html css reactjs
<div class={this.props.navbar}>
should be<div className={this.props.navbar}>
asclass
is the reserved keyword. Same for<a href="#" class="navbar-brand">
. See this reactjs.org/docs/…
– Hardik Modha
Nov 20 '18 at 9:16
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
1
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce afixedToTop
prop and set its corresponding class name if it istrue
.
– trixn
Nov 20 '18 at 9:31
add a comment |
I'm just wondering is putting your className
classes inside the prop in React class? Here is my code so far.
var app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header navbar="navbar fixed-top navbar-custom"/>
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
return(
<header>
<div class={this.props.navbar}>
<a href="#" class="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
Thanks for the constructive advice.
javascript html css reactjs
I'm just wondering is putting your className
classes inside the prop in React class? Here is my code so far.
var app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header navbar="navbar fixed-top navbar-custom"/>
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
return(
<header>
<div class={this.props.navbar}>
<a href="#" class="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
Thanks for the constructive advice.
javascript html css reactjs
javascript html css reactjs
edited Nov 20 '18 at 9:30
kit
1,1063716
1,1063716
asked Nov 20 '18 at 9:15
Ben SwindellsBen Swindells
1809
1809
<div class={this.props.navbar}>
should be<div className={this.props.navbar}>
asclass
is the reserved keyword. Same for<a href="#" class="navbar-brand">
. See this reactjs.org/docs/…
– Hardik Modha
Nov 20 '18 at 9:16
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
1
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce afixedToTop
prop and set its corresponding class name if it istrue
.
– trixn
Nov 20 '18 at 9:31
add a comment |
<div class={this.props.navbar}>
should be<div className={this.props.navbar}>
asclass
is the reserved keyword. Same for<a href="#" class="navbar-brand">
. See this reactjs.org/docs/…
– Hardik Modha
Nov 20 '18 at 9:16
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
1
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce afixedToTop
prop and set its corresponding class name if it istrue
.
– trixn
Nov 20 '18 at 9:31
<div class={this.props.navbar}>
should be <div className={this.props.navbar}>
as class
is the reserved keyword. Same for <a href="#" class="navbar-brand">
. See this reactjs.org/docs/…– Hardik Modha
Nov 20 '18 at 9:16
<div class={this.props.navbar}>
should be <div className={this.props.navbar}>
as class
is the reserved keyword. Same for <a href="#" class="navbar-brand">
. See this reactjs.org/docs/…– Hardik Modha
Nov 20 '18 at 9:16
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
1
1
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce a fixedToTop
prop and set its corresponding class name if it is true
.– trixn
Nov 20 '18 at 9:31
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce a fixedToTop
prop and set its corresponding class name if it is true
.– trixn
Nov 20 '18 at 9:31
add a comment |
5 Answers
5
active
oldest
votes
It is not a bad idea.
Just prefer use className
React attribute instead of class
<header>
<div className={this.props.navbar}>
/* Your code */
</div>
</header>
add a comment |
I would say , why don't you instantiate a class object in state? so the properties of the class will be in the props.
add a comment |
Is it good idea? yes. Everytime? No
I would suggest you should only do this where the component is reusable in the global scope of the application. There are some cases when the html structure is usually same but the classes name are different. In these you can make classNames as props (also set default classes as default value).
In the end it is the design choice really of what level of generalization you need to have with your component some times abstracting everything means you need to manage everything which could be frustrating at times.
add a comment |
It can be a good idea or not, in fact, everything relays on your implementation logic.
You'll always find many ways to do the same implementation, the best one I would say, is the one that relays at most on the SOLID Principles.
Let's see some example of the same implementation you exposed:
1) Exposing only Header boolean properties
to customise the behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header isFixed isCustom />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { isFixed, isCustom } = this.props;
return(
<header>
<div className=`navbar ${isFixed ? 'fixed-top' : ''} ${isFixed ? 'navbar-custom' : ''}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
2) Extending the css class
for unpredictables behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header classExtended='fixed-top' />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { classExtended } = this.props;
return(
<header>
<div className=`navbar navbar-custom ${classExtended}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
3) You own example.
The best case scenario is analyse with those cases might fit better for your project requirements and life cycle, giving you the ability to refactor your code with easy.
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
add a comment |
To judge if this is a good idea, it is important to think about where the approach to pass classNames as props is leading when your application growth. In a complex application you would probably end-up managing your data as well as your classNames in a top-level component and pass both down to child components.
However, isn't data what effects your dynamic styles?
So it would be better to manage your dynamic assignment of classes within components and only pass the bits of data to components they need to render.
So long story short: It doesn't scale so don't do it if you want to build a complex app.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389685%2fis-it-a-good-idea-to-put-all-classname-classes-as-a-prop-in-react%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is not a bad idea.
Just prefer use className
React attribute instead of class
<header>
<div className={this.props.navbar}>
/* Your code */
</div>
</header>
add a comment |
It is not a bad idea.
Just prefer use className
React attribute instead of class
<header>
<div className={this.props.navbar}>
/* Your code */
</div>
</header>
add a comment |
It is not a bad idea.
Just prefer use className
React attribute instead of class
<header>
<div className={this.props.navbar}>
/* Your code */
</div>
</header>
It is not a bad idea.
Just prefer use className
React attribute instead of class
<header>
<div className={this.props.navbar}>
/* Your code */
</div>
</header>
answered Nov 20 '18 at 9:19
Florian BurgevinFlorian Burgevin
111
111
add a comment |
add a comment |
I would say , why don't you instantiate a class object in state? so the properties of the class will be in the props.
add a comment |
I would say , why don't you instantiate a class object in state? so the properties of the class will be in the props.
add a comment |
I would say , why don't you instantiate a class object in state? so the properties of the class will be in the props.
I would say , why don't you instantiate a class object in state? so the properties of the class will be in the props.
answered Nov 20 '18 at 9:45
Saad MaqboolSaad Maqbool
1869
1869
add a comment |
add a comment |
Is it good idea? yes. Everytime? No
I would suggest you should only do this where the component is reusable in the global scope of the application. There are some cases when the html structure is usually same but the classes name are different. In these you can make classNames as props (also set default classes as default value).
In the end it is the design choice really of what level of generalization you need to have with your component some times abstracting everything means you need to manage everything which could be frustrating at times.
add a comment |
Is it good idea? yes. Everytime? No
I would suggest you should only do this where the component is reusable in the global scope of the application. There are some cases when the html structure is usually same but the classes name are different. In these you can make classNames as props (also set default classes as default value).
In the end it is the design choice really of what level of generalization you need to have with your component some times abstracting everything means you need to manage everything which could be frustrating at times.
add a comment |
Is it good idea? yes. Everytime? No
I would suggest you should only do this where the component is reusable in the global scope of the application. There are some cases when the html structure is usually same but the classes name are different. In these you can make classNames as props (also set default classes as default value).
In the end it is the design choice really of what level of generalization you need to have with your component some times abstracting everything means you need to manage everything which could be frustrating at times.
Is it good idea? yes. Everytime? No
I would suggest you should only do this where the component is reusable in the global scope of the application. There are some cases when the html structure is usually same but the classes name are different. In these you can make classNames as props (also set default classes as default value).
In the end it is the design choice really of what level of generalization you need to have with your component some times abstracting everything means you need to manage everything which could be frustrating at times.
answered Nov 20 '18 at 9:59
Ahsan SohailAhsan Sohail
421312
421312
add a comment |
add a comment |
It can be a good idea or not, in fact, everything relays on your implementation logic.
You'll always find many ways to do the same implementation, the best one I would say, is the one that relays at most on the SOLID Principles.
Let's see some example of the same implementation you exposed:
1) Exposing only Header boolean properties
to customise the behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header isFixed isCustom />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { isFixed, isCustom } = this.props;
return(
<header>
<div className=`navbar ${isFixed ? 'fixed-top' : ''} ${isFixed ? 'navbar-custom' : ''}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
2) Extending the css class
for unpredictables behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header classExtended='fixed-top' />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { classExtended } = this.props;
return(
<header>
<div className=`navbar navbar-custom ${classExtended}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
3) You own example.
The best case scenario is analyse with those cases might fit better for your project requirements and life cycle, giving you the ability to refactor your code with easy.
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
add a comment |
It can be a good idea or not, in fact, everything relays on your implementation logic.
You'll always find many ways to do the same implementation, the best one I would say, is the one that relays at most on the SOLID Principles.
Let's see some example of the same implementation you exposed:
1) Exposing only Header boolean properties
to customise the behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header isFixed isCustom />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { isFixed, isCustom } = this.props;
return(
<header>
<div className=`navbar ${isFixed ? 'fixed-top' : ''} ${isFixed ? 'navbar-custom' : ''}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
2) Extending the css class
for unpredictables behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header classExtended='fixed-top' />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { classExtended } = this.props;
return(
<header>
<div className=`navbar navbar-custom ${classExtended}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
3) You own example.
The best case scenario is analyse with those cases might fit better for your project requirements and life cycle, giving you the ability to refactor your code with easy.
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
add a comment |
It can be a good idea or not, in fact, everything relays on your implementation logic.
You'll always find many ways to do the same implementation, the best one I would say, is the one that relays at most on the SOLID Principles.
Let's see some example of the same implementation you exposed:
1) Exposing only Header boolean properties
to customise the behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header isFixed isCustom />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { isFixed, isCustom } = this.props;
return(
<header>
<div className=`navbar ${isFixed ? 'fixed-top' : ''} ${isFixed ? 'navbar-custom' : ''}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
2) Extending the css class
for unpredictables behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header classExtended='fixed-top' />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { classExtended } = this.props;
return(
<header>
<div className=`navbar navbar-custom ${classExtended}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
3) You own example.
The best case scenario is analyse with those cases might fit better for your project requirements and life cycle, giving you the ability to refactor your code with easy.
It can be a good idea or not, in fact, everything relays on your implementation logic.
You'll always find many ways to do the same implementation, the best one I would say, is the one that relays at most on the SOLID Principles.
Let's see some example of the same implementation you exposed:
1) Exposing only Header boolean properties
to customise the behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header isFixed isCustom />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { isFixed, isCustom } = this.props;
return(
<header>
<div className=`navbar ${isFixed ? 'fixed-top' : ''} ${isFixed ? 'navbar-custom' : ''}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
2) Extending the css class
for unpredictables behaviour:
const app = document.getElementById('app');
class App extends React.Component {
render() {
return(
<div>
<Header classExtended='fixed-top' />
</div>
);
}
}
class Header extends React.Component {
constructor(props) {
super(props);
}
render() {
const { classExtended } = this.props;
return(
<header>
<div className=`navbar navbar-custom ${classExtended}`>
<a href="#" className="navbar-brand">Material Site</a>
<a href="#"><img src="/images/hamburger-icon.png" width="30" height="20"></img></a>
</div>
</header>
);
}
}
class ChildSidebar extends React.Component {}
ReactDOM.render(<App/>, app);
3) You own example.
The best case scenario is analyse with those cases might fit better for your project requirements and life cycle, giving you the ability to refactor your code with easy.
answered Nov 20 '18 at 10:17
Marcos GonçalvesMarcos Gonçalves
421
421
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
add a comment |
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
1
1
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
This is real helpful thank you!
– Ben Swindells
Nov 20 '18 at 10:24
add a comment |
To judge if this is a good idea, it is important to think about where the approach to pass classNames as props is leading when your application growth. In a complex application you would probably end-up managing your data as well as your classNames in a top-level component and pass both down to child components.
However, isn't data what effects your dynamic styles?
So it would be better to manage your dynamic assignment of classes within components and only pass the bits of data to components they need to render.
So long story short: It doesn't scale so don't do it if you want to build a complex app.
add a comment |
To judge if this is a good idea, it is important to think about where the approach to pass classNames as props is leading when your application growth. In a complex application you would probably end-up managing your data as well as your classNames in a top-level component and pass both down to child components.
However, isn't data what effects your dynamic styles?
So it would be better to manage your dynamic assignment of classes within components and only pass the bits of data to components they need to render.
So long story short: It doesn't scale so don't do it if you want to build a complex app.
add a comment |
To judge if this is a good idea, it is important to think about where the approach to pass classNames as props is leading when your application growth. In a complex application you would probably end-up managing your data as well as your classNames in a top-level component and pass both down to child components.
However, isn't data what effects your dynamic styles?
So it would be better to manage your dynamic assignment of classes within components and only pass the bits of data to components they need to render.
So long story short: It doesn't scale so don't do it if you want to build a complex app.
To judge if this is a good idea, it is important to think about where the approach to pass classNames as props is leading when your application growth. In a complex application you would probably end-up managing your data as well as your classNames in a top-level component and pass both down to child components.
However, isn't data what effects your dynamic styles?
So it would be better to manage your dynamic assignment of classes within components and only pass the bits of data to components they need to render.
So long story short: It doesn't scale so don't do it if you want to build a complex app.
edited Nov 20 '18 at 9:38
answered Nov 20 '18 at 9:24
Fabian HinsenkampFabian Hinsenkamp
1615
1615
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389685%2fis-it-a-good-idea-to-put-all-classname-classes-as-a-prop-in-react%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
<div class={this.props.navbar}>
should be<div className={this.props.navbar}>
asclass
is the reserved keyword. Same for<a href="#" class="navbar-brand">
. See this reactjs.org/docs/…– Hardik Modha
Nov 20 '18 at 9:16
Unless the classname changes according to some condition or in different instance of the Header component, its probably better to write them as a static value inside the component, else a prop is okay. Also in JSX use className instead of class
– Shubham Khatri
Nov 20 '18 at 9:17
Ah yes my bad the class works within my live server and doesnt flag as an error, but I will change this thanks for the feedback :)
– Ben Swindells
Nov 20 '18 at 9:19
1
classnames
is also a helpful tool to dynamically build a class name. You could the e.g. introduce afixedToTop
prop and set its corresponding class name if it istrue
.– trixn
Nov 20 '18 at 9:31