React: Is it possible to declare some props as “const” (not allowed to changed during mount)
Some props are not expected to change during the lifetime of the component. They're typically used to initialize some things in the constructor.
It's a waste of time to handle updates of these props in componentWillReceiveProps if they'll never change in practice.
But such props feel like inviting hard-to-find bugs to your house. Things should blow up if they do change.
I could add asserts inside componentWillReceiveProps but it would be much smoother if it could be declared as part of the PropTypes.
Maybe using props like this is an antipattern(?), but for certain types of components if seems hard to avoid.
reactjs
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
add a comment |
Some props are not expected to change during the lifetime of the component. They're typically used to initialize some things in the constructor.
It's a waste of time to handle updates of these props in componentWillReceiveProps if they'll never change in practice.
But such props feel like inviting hard-to-find bugs to your house. Things should blow up if they do change.
I could add asserts inside componentWillReceiveProps but it would be much smoother if it could be declared as part of the PropTypes.
Maybe using props like this is an antipattern(?), but for certain types of components if seems hard to avoid.
reactjs
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have<EditThing id={} />component connected to Router; once current location is changed from /edit/1 to /edit/2 the sameRouteis rendered. And it want to update<EditThing />instead of creating one. If you block props from changes somehow you will get your component out-of-date.
– skyboyer
Nov 23 '18 at 15:04
add a comment |
Some props are not expected to change during the lifetime of the component. They're typically used to initialize some things in the constructor.
It's a waste of time to handle updates of these props in componentWillReceiveProps if they'll never change in practice.
But such props feel like inviting hard-to-find bugs to your house. Things should blow up if they do change.
I could add asserts inside componentWillReceiveProps but it would be much smoother if it could be declared as part of the PropTypes.
Maybe using props like this is an antipattern(?), but for certain types of components if seems hard to avoid.
reactjs
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
Some props are not expected to change during the lifetime of the component. They're typically used to initialize some things in the constructor.
It's a waste of time to handle updates of these props in componentWillReceiveProps if they'll never change in practice.
But such props feel like inviting hard-to-find bugs to your house. Things should blow up if they do change.
I could add asserts inside componentWillReceiveProps but it would be much smoother if it could be declared as part of the PropTypes.
Maybe using props like this is an antipattern(?), but for certain types of components if seems hard to avoid.
reactjs
reactjs
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
asked Nov 23 '18 at 14:56
olejorgenbolejorgenb
539613
539613
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have<EditThing id={} />component connected to Router; once current location is changed from /edit/1 to /edit/2 the sameRouteis rendered. And it want to update<EditThing />instead of creating one. If you block props from changes somehow you will get your component out-of-date.
– skyboyer
Nov 23 '18 at 15:04
add a comment |
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have<EditThing id={} />component connected to Router; once current location is changed from /edit/1 to /edit/2 the sameRouteis rendered. And it want to update<EditThing />instead of creating one. If you block props from changes somehow you will get your component out-of-date.
– skyboyer
Nov 23 '18 at 15:04
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have
<EditThing id={} /> component connected to Router; once current location is changed from /edit/1 to /edit/2 the same Route is rendered. And it want to update <EditThing /> instead of creating one. If you block props from changes somehow you will get your component out-of-date.– skyboyer
Nov 23 '18 at 15:04
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have
<EditThing id={} /> component connected to Router; once current location is changed from /edit/1 to /edit/2 the same Route is rendered. And it want to update <EditThing /> instead of creating one. If you block props from changes somehow you will get your component out-of-date.– skyboyer
Nov 23 '18 at 15:04
add a comment |
0
active
oldest
votes
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%2f53448905%2freact-is-it-possible-to-declare-some-props-as-const-not-allowed-to-changed-d%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f53448905%2freact-is-it-possible-to-declare-some-props-as-const-not-allowed-to-changed-d%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
don't treat this like a bug. also blocking props from changes may lead to some issues. example: assume we have
<EditThing id={} />component connected to Router; once current location is changed from /edit/1 to /edit/2 the sameRouteis rendered. And it want to update<EditThing />instead of creating one. If you block props from changes somehow you will get your component out-of-date.– skyboyer
Nov 23 '18 at 15:04