Is Flow replace PropTypes?
up vote
0
down vote
favorite
I'm using React with Flow. If I forgot to set some requiring props when rendering, Flow gives me error so I can prevent the problem.
However Flow is not actually working on runtime. So if the value that I used were treated as number wasn't number, Flow can't catch this. For example, if the value was coming from somewhere else, like server side and if it was string, but Flow just treated as number so eventually I will get some errors in runtime.
But PropTypes works in runtime, so in the same case I'll get the error message that PropType expected number but actually it was string.
It's also possible to happen when the API were changed and returning data is different. It could undefined or whatever, possibly not actual value I expected.
So I'm using Flow and PropTypes both actually, however I searched on about using both together, but couldn't find any related informations.
Instead, all I found was just "Flow" replaces "PropTypes". I don't think so, I already mentioned about difference between these two. These two works totally different and each of them have so many good benefits to use, so combine them will have nice synergy, I think.
However now I'm using both, I have to define types for props and also define propTypes and defaultProps always, and it makes my code actually pretty long and takes lots of time just make single component.
Should I stop using Flow and PropTypes together? I think Flow is better than PropTypes, there were so much benefits when using static type checker so I want to keep using it. Also there's nice VSCode support for Flow, but not proptypes.
If I use Flow, is PropTypes doesn't needed? Any advice will appreciate it.
reactjs flowtype react-proptypes
edited Nov 22 at 22:12
skyboyer
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
add a comment |
up vote
0
down vote
favorite
I'm using React with Flow. If I forgot to set some requiring props when rendering, Flow gives me error so I can prevent the problem.
However Flow is not actually working on runtime. So if the value that I used were treated as number wasn't number, Flow can't catch this. For example, if the value was coming from somewhere else, like server side and if it was string, but Flow just treated as number so eventually I will get some errors in runtime.
But PropTypes works in runtime, so in the same case I'll get the error message that PropType expected number but actually it was string.
It's also possible to happen when the API were changed and returning data is different. It could undefined or whatever, possibly not actual value I expected.
So I'm using Flow and PropTypes both actually, however I searched on about using both together, but couldn't find any related informations.
Instead, all I found was just "Flow" replaces "PropTypes". I don't think so, I already mentioned about difference between these two. These two works totally different and each of them have so many good benefits to use, so combine them will have nice synergy, I think.
However now I'm using both, I have to define types for props and also define propTypes and defaultProps always, and it makes my code actually pretty long and takes lots of time just make single component.
Should I stop using Flow and PropTypes together? I think Flow is better than PropTypes, there were so much benefits when using static type checker so I want to keep using it. Also there's nice VSCode support for Flow, but not proptypes.
If I use Flow, is PropTypes doesn't needed? Any advice will appreciate it.
reactjs flowtype react-proptypes
edited Nov 22 at 22:12
skyboyer
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
1
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
1
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm using React with Flow. If I forgot to set some requiring props when rendering, Flow gives me error so I can prevent the problem.
However Flow is not actually working on runtime. So if the value that I used were treated as number wasn't number, Flow can't catch this. For example, if the value was coming from somewhere else, like server side and if it was string, but Flow just treated as number so eventually I will get some errors in runtime.
But PropTypes works in runtime, so in the same case I'll get the error message that PropType expected number but actually it was string.
It's also possible to happen when the API were changed and returning data is different. It could undefined or whatever, possibly not actual value I expected.
So I'm using Flow and PropTypes both actually, however I searched on about using both together, but couldn't find any related informations.
Instead, all I found was just "Flow" replaces "PropTypes". I don't think so, I already mentioned about difference between these two. These two works totally different and each of them have so many good benefits to use, so combine them will have nice synergy, I think.
However now I'm using both, I have to define types for props and also define propTypes and defaultProps always, and it makes my code actually pretty long and takes lots of time just make single component.
Should I stop using Flow and PropTypes together? I think Flow is better than PropTypes, there were so much benefits when using static type checker so I want to keep using it. Also there's nice VSCode support for Flow, but not proptypes.
If I use Flow, is PropTypes doesn't needed? Any advice will appreciate it.
reactjs flowtype react-proptypes
edited Nov 22 at 22:12
skyboyer
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
I'm using React with Flow. If I forgot to set some requiring props when rendering, Flow gives me error so I can prevent the problem.
However Flow is not actually working on runtime. So if the value that I used were treated as number wasn't number, Flow can't catch this. For example, if the value was coming from somewhere else, like server side and if it was string, but Flow just treated as number so eventually I will get some errors in runtime.
But PropTypes works in runtime, so in the same case I'll get the error message that PropType expected number but actually it was string.
It's also possible to happen when the API were changed and returning data is different. It could undefined or whatever, possibly not actual value I expected.
So I'm using Flow and PropTypes both actually, however I searched on about using both together, but couldn't find any related informations.
Instead, all I found was just "Flow" replaces "PropTypes". I don't think so, I already mentioned about difference between these two. These two works totally different and each of them have so many good benefits to use, so combine them will have nice synergy, I think.
However now I'm using both, I have to define types for props and also define propTypes and defaultProps always, and it makes my code actually pretty long and takes lots of time just make single component.
Should I stop using Flow and PropTypes together? I think Flow is better than PropTypes, there were so much benefits when using static type checker so I want to keep using it. Also there's nice VSCode support for Flow, but not proptypes.
If I use Flow, is PropTypes doesn't needed? Any advice will appreciate it.
reactjs flowtype react-proptypes
reactjs flowtype react-proptypes
edited Nov 22 at 22:12
skyboyer
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
edited Nov 22 at 22:12
skyboyer
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
edited Nov 22 at 22:12
skyboyer
3,18611128
edited Nov 22 at 22:12
skyboyer
3,18611128
edited Nov 22 at 22:12
skyboyer
3,18611128
3,18611128
asked Nov 22 at 15:53
modernator
1,24032448
asked Nov 22 at 15:53
modernator
1,24032448
asked Nov 22 at 15:53
modernator
1,24032448
1,24032448
1
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
1
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23
add a comment |
1
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
1
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23
1
1
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
1
1
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
answered Nov 22 at 22:22
skyboyer
3,18611128
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%2f53434518%2fis-flow-replace-proptypes%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
up vote
1
down vote
accepted
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
answered Nov 22 at 22:22
skyboyer
3,18611128
add a comment |
up vote
1
down vote
accepted
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
answered Nov 22 at 22:22
skyboyer
3,18611128
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
answered Nov 22 at 22:22
skyboyer
3,18611128
Flow allows you provide types for anything.
PropTypes is just for component's props so it cannot help with typing variable or method. It even does not have easy way for tyyping callback props. You will need to describe custom validator.
Also PropTypes works on per-prop basis. You cannot describe independent subsets of props. E.g. "having field NAME is required only if nickname is empty". I agree that this sounds not really helpful with this example. But it still means flow is more flexible.
And btw having typecheck in production is bad idea anyway - it would lead to performance penalty. At the same time most type issues will already be caught. While it still does not save you from issues in logic - so you will need to test that with manual/acceptance/integration tests.
answered Nov 22 at 22:22
skyboyer
3,18611128
edited Nov 22 at 22:28
answered Nov 22 at 22:22
skyboyer
3,18611128
answered Nov 22 at 22:22
skyboyer
3,18611128
answered Nov 22 at 22:22
skyboyer
3,18611128
3,18611128
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53434518%2fis-flow-replace-proptypes%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
1
flow can work at runtime if you use flow-runtime. However, it can significantly slow your app because the checks will be everywhere, not only in component properties.
– Sulthan
Nov 22 at 15:57
1
As you said, propTypes works at runtime so it provides more accurate type-checking. If you want another alternative you can take a look at Typescript 3.0 where type will be convert to propTypes for react components. [Document][1] [1]: typescriptlang.org/docs/handbook/release-notes/…
– Daniel Tran
Nov 22 at 16:03
@DanielTran Wow, that's amazing!
– modernator
Nov 22 at 17:23