Declaring React state, in constructor, versus out of constructor
Is there any difference of declaring state
, out of constructor?
I have an example of a component here:
class BurgerBuilder extends Component {
state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
....
}
Here I just declare a variable called state, which includes the variables of the component, but I don't call a constructor.
Where as i declare:
class BurgerBuilder extends Component {
constructor() {
super();
this.state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
}
....
}
I found, that I can use this.setState
for both solutions and that there is no real difference in my project. Is there a best practice, on what to use where.
reactjs components state
add a comment |
Is there any difference of declaring state
, out of constructor?
I have an example of a component here:
class BurgerBuilder extends Component {
state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
....
}
Here I just declare a variable called state, which includes the variables of the component, but I don't call a constructor.
Where as i declare:
class BurgerBuilder extends Component {
constructor() {
super();
this.state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
}
....
}
I found, that I can use this.setState
for both solutions and that there is no real difference in my project. Is there a best practice, on what to use where.
reactjs components state
add a comment |
Is there any difference of declaring state
, out of constructor?
I have an example of a component here:
class BurgerBuilder extends Component {
state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
....
}
Here I just declare a variable called state, which includes the variables of the component, but I don't call a constructor.
Where as i declare:
class BurgerBuilder extends Component {
constructor() {
super();
this.state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
}
....
}
I found, that I can use this.setState
for both solutions and that there is no real difference in my project. Is there a best practice, on what to use where.
reactjs components state
Is there any difference of declaring state
, out of constructor?
I have an example of a component here:
class BurgerBuilder extends Component {
state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
....
}
Here I just declare a variable called state, which includes the variables of the component, but I don't call a constructor.
Where as i declare:
class BurgerBuilder extends Component {
constructor() {
super();
this.state = {
ingredients: {
salad: 0,
bacon: 0,
cheese: 0,
meat: 0
},
totalPrice: 30
};
}
....
}
I found, that I can use this.setState
for both solutions and that there is no real difference in my project. Is there a best practice, on what to use where.
reactjs components state
reactjs components state
edited Nov 12 '18 at 13:03
Nguyễn Thanh Tú
4,6393827
4,6393827
asked Nov 12 '18 at 12:55
baileyhaldwinbaileyhaldwin
664117
664117
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Is there any difference? Is there a best practice, on what to use
where?
They're almost the same. The syntax for declaring the state
without contructor()
is syntactic sugar.
What you're using in the first example is called Class field declarations. (This proposal reached Stage 3 in July 2017).
In short, this proposal allows us a simpler syntax for declaring class fields, without the need for the constructor()
.
For example, those codes are written using ES2015
class Counter extends HTMLElement {
constructor() {
super();
this.onclick = this.clicked.bind(this);
this.x = 0;
}
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
By using Class field declarations, they will be like this:
class Counter extends HTMLElement {
x = 0;
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
constructor() {
super();
this.onclick = this.clicked.bind(this);
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
The benefits of using this syntax:
By declaring fields up-front, class definitions become more
self-documenting; instances go through fewer state transitions, as
declared fields are always present.
Reference: Class field declarations for JavaScript
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%2f53262646%2fdeclaring-react-state-in-constructor-versus-out-of-constructor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Is there any difference? Is there a best practice, on what to use
where?
They're almost the same. The syntax for declaring the state
without contructor()
is syntactic sugar.
What you're using in the first example is called Class field declarations. (This proposal reached Stage 3 in July 2017).
In short, this proposal allows us a simpler syntax for declaring class fields, without the need for the constructor()
.
For example, those codes are written using ES2015
class Counter extends HTMLElement {
constructor() {
super();
this.onclick = this.clicked.bind(this);
this.x = 0;
}
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
By using Class field declarations, they will be like this:
class Counter extends HTMLElement {
x = 0;
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
constructor() {
super();
this.onclick = this.clicked.bind(this);
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
The benefits of using this syntax:
By declaring fields up-front, class definitions become more
self-documenting; instances go through fewer state transitions, as
declared fields are always present.
Reference: Class field declarations for JavaScript
add a comment |
Is there any difference? Is there a best practice, on what to use
where?
They're almost the same. The syntax for declaring the state
without contructor()
is syntactic sugar.
What you're using in the first example is called Class field declarations. (This proposal reached Stage 3 in July 2017).
In short, this proposal allows us a simpler syntax for declaring class fields, without the need for the constructor()
.
For example, those codes are written using ES2015
class Counter extends HTMLElement {
constructor() {
super();
this.onclick = this.clicked.bind(this);
this.x = 0;
}
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
By using Class field declarations, they will be like this:
class Counter extends HTMLElement {
x = 0;
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
constructor() {
super();
this.onclick = this.clicked.bind(this);
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
The benefits of using this syntax:
By declaring fields up-front, class definitions become more
self-documenting; instances go through fewer state transitions, as
declared fields are always present.
Reference: Class field declarations for JavaScript
add a comment |
Is there any difference? Is there a best practice, on what to use
where?
They're almost the same. The syntax for declaring the state
without contructor()
is syntactic sugar.
What you're using in the first example is called Class field declarations. (This proposal reached Stage 3 in July 2017).
In short, this proposal allows us a simpler syntax for declaring class fields, without the need for the constructor()
.
For example, those codes are written using ES2015
class Counter extends HTMLElement {
constructor() {
super();
this.onclick = this.clicked.bind(this);
this.x = 0;
}
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
By using Class field declarations, they will be like this:
class Counter extends HTMLElement {
x = 0;
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
constructor() {
super();
this.onclick = this.clicked.bind(this);
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
The benefits of using this syntax:
By declaring fields up-front, class definitions become more
self-documenting; instances go through fewer state transitions, as
declared fields are always present.
Reference: Class field declarations for JavaScript
Is there any difference? Is there a best practice, on what to use
where?
They're almost the same. The syntax for declaring the state
without contructor()
is syntactic sugar.
What you're using in the first example is called Class field declarations. (This proposal reached Stage 3 in July 2017).
In short, this proposal allows us a simpler syntax for declaring class fields, without the need for the constructor()
.
For example, those codes are written using ES2015
class Counter extends HTMLElement {
constructor() {
super();
this.onclick = this.clicked.bind(this);
this.x = 0;
}
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
By using Class field declarations, they will be like this:
class Counter extends HTMLElement {
x = 0;
clicked() {
this.x++;
window.requestAnimationFrame(this.render.bind(this));
}
constructor() {
super();
this.onclick = this.clicked.bind(this);
}
connectedCallback() { this.render(); }
render() {
this.textContent = this.x.toString();
}
}
window.customElements.define('num-counter', Counter);
The benefits of using this syntax:
By declaring fields up-front, class definitions become more
self-documenting; instances go through fewer state transitions, as
declared fields are always present.
Reference: Class field declarations for JavaScript
answered Nov 12 '18 at 13:20
Nguyễn Thanh TúNguyễn Thanh Tú
4,6393827
4,6393827
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%2f53262646%2fdeclaring-react-state-in-constructor-versus-out-of-constructor%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