Correct way to fetch data with server side rendering (Next.js, when to use componentDidMount and when to use...

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}

I am using Next.js, in the _app.js page (where we set a general webapp state) I have 2 types of data that I need to have in the header (so for every component).

1) The first type is the header info, this info should be rendered before the app loads. I will use get getInitialProps to call the endpoints and put them into the props and then to componentWillMount to add them to the state.

2) The second type is the data for the Search component, it as a lot of data and I don't particularly mind loading it while the app is already rendered as It is not displayed in the first user visual.
So I am gussing that here it is much better prefered to use componentDidMount and asynchorslly call the endpoint that fetches the serach object data and than adding setting the state with it.

The purpose of this questionis double:

1) Review - Am I thinking about this correctly or did I miss something?

2) Question - now, when the data is loaded after first render, I am passing the data like so: _app.js -> Layout -> Menu -> SearchBar
so my question is, in my searchBar I need to do something like

componentDidMount() {

    this.setState({ options: this.props.searchBarSource })

}

But, because _app.js is filling this data with an async call, wouldn't this mean that I will always get an empty object?
WWhat is the correct way to solve this? If I setTimeOut to around 3 seconds and then set the data is it a normal solution or very hacky and there are better ways?

asked Jan 3 at 12:39

Contentop

12310

1

you can use life-cycles to detect changes in this.props.searchBarSource and store accordingly. But do you really need to synchronize props to state? Can't you use this.props.searchBarSource where you normally would use this.state.options?

– Kunukn
Jan 3 at 13:58

add a comment |

I am using Next.js, in the _app.js page (where we set a general webapp state) I have 2 types of data that I need to have in the header (so for every component).

The purpose of this questionis double:

1) Review - Am I thinking about this correctly or did I miss something?

2) Question - now, when the data is loaded after first render, I am passing the data like so: _app.js -> Layout -> Menu -> SearchBar
so my question is, in my searchBar I need to do something like

componentDidMount() {

    this.setState({ options: this.props.searchBarSource })

}

asked Jan 3 at 12:39

Contentop

12310

1

you can use life-cycles to detect changes in this.props.searchBarSource and store accordingly. But do you really need to synchronize props to state? Can't you use this.props.searchBarSource where you normally would use this.state.options?

– Kunukn
Jan 3 at 13:58

add a comment |

I am using Next.js, in the _app.js page (where we set a general webapp state) I have 2 types of data that I need to have in the header (so for every component).

The purpose of this questionis double:

1) Review - Am I thinking about this correctly or did I miss something?

2) Question - now, when the data is loaded after first render, I am passing the data like so: _app.js -> Layout -> Menu -> SearchBar
so my question is, in my searchBar I need to do something like

componentDidMount() {

    this.setState({ options: this.props.searchBarSource })

}

asked Jan 3 at 12:39

Contentop

12310

I am using Next.js, in the _app.js page (where we set a general webapp state) I have 2 types of data that I need to have in the header (so for every component).

The purpose of this questionis double:

1) Review - Am I thinking about this correctly or did I miss something?

2) Question - now, when the data is loaded after first render, I am passing the data like so: _app.js -> Layout -> Menu -> SearchBar
so my question is, in my searchBar I need to do something like

componentDidMount() {

    this.setState({ options: this.props.searchBarSource })

}

reactjs serverside-rendering next.js ssr react-lifecycle

asked Jan 3 at 12:39

Contentop

12310

asked Jan 3 at 12:39

Contentop

12310

asked Jan 3 at 12:39

Contentop

12310

asked Jan 3 at 12:39

Contentop

12310

asked Jan 3 at 12:39

Contentop

12310

1

you can use life-cycles to detect changes in this.props.searchBarSource and store accordingly. But do you really need to synchronize props to state? Can't you use this.props.searchBarSource where you normally would use this.state.options?

– Kunukn
Jan 3 at 13:58

add a comment |

1

you can use life-cycles to detect changes in this.props.searchBarSource and store accordingly. But do you really need to synchronize props to state? Can't you use this.props.searchBarSource where you normally would use this.state.options?

– Kunukn
Jan 3 at 13:58

you can use life-cycles to detect changes in this.props.searchBarSource and store accordingly. But do you really need to synchronize props to state? Can't you use this.props.searchBarSource where you normally would use this.state.options?

– Kunukn
Jan 3 at 13:58

add a comment |

1 Answer
1

active

oldest

votes

What your are trying to do makes sense. Coming to NextJS, you need to be very deliberate about which data should load server side and which shouldn't.

Here are some pointers:

There is no need to setState in the search component, you can
use this.props.searchBarSource as Kunukn mentioned.

[Note - If you are combining getInitialProps and client side (shallow routing), when the user navigates to a new client side route, the initialProps will be undefined. A workaround might be to store initialProps in state or Local Storage.]

The point of getInitialProps is to load async data before the
component mounts. You will always receive the resolved Promise on
componentDidMount, so your this.props.searchBarSource will never
be empty (or more correctly, pending).

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

1

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

1

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

1

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

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
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54022472%2fcorrect-way-to-fetch-data-with-server-side-rendering-next-js-when-to-use-compo%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

What your are trying to do makes sense. Coming to NextJS, you need to be very deliberate about which data should load server side and which shouldn't.

Here are some pointers:

There is no need to setState in the search component, you can
use this.props.searchBarSource as Kunukn mentioned.

[Note - If you are combining getInitialProps and client side (shallow routing), when the user navigates to a new client side route, the initialProps will be undefined. A workaround might be to store initialProps in state or Local Storage.]

The point of getInitialProps is to load async data before the
component mounts. You will always receive the resolved Promise on
componentDidMount, so your this.props.searchBarSource will never
be empty (or more correctly, pending).

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

1

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

1

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

1

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

add a comment |

What your are trying to do makes sense. Coming to NextJS, you need to be very deliberate about which data should load server side and which shouldn't.

Here are some pointers:

There is no need to setState in the search component, you can
use this.props.searchBarSource as Kunukn mentioned.

[Note - If you are combining getInitialProps and client side (shallow routing), when the user navigates to a new client side route, the initialProps will be undefined. A workaround might be to store initialProps in state or Local Storage.]

The point of getInitialProps is to load async data before the
component mounts. You will always receive the resolved Promise on
componentDidMount, so your this.props.searchBarSource will never
be empty (or more correctly, pending).

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

1

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

1

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

1

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

add a comment |

What your are trying to do makes sense. Coming to NextJS, you need to be very deliberate about which data should load server side and which shouldn't.

Here are some pointers:

There is no need to setState in the search component, you can
use this.props.searchBarSource as Kunukn mentioned.

[Note - If you are combining getInitialProps and client side (shallow routing), when the user navigates to a new client side route, the initialProps will be undefined. A workaround might be to store initialProps in state or Local Storage.]

The point of getInitialProps is to load async data before the
component mounts. You will always receive the resolved Promise on
componentDidMount, so your this.props.searchBarSource will never
be empty (or more correctly, pending).

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

What your are trying to do makes sense. Coming to NextJS, you need to be very deliberate about which data should load server side and which shouldn't.

Here are some pointers:

There is no need to setState in the search component, you can
use this.props.searchBarSource as Kunukn mentioned.

[Note - If you are combining getInitialProps and client side (shallow routing), when the user navigates to a new client side route, the initialProps will be undefined. A workaround might be to store initialProps in state or Local Storage.]

The point of getInitialProps is to load async data before the
component mounts. You will always receive the resolved Promise on
componentDidMount, so your this.props.searchBarSource will never
be empty (or more correctly, pending).

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

edited Jan 3 at 17:46

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

answered Jan 3 at 15:05

Avremel Kaminetzky

523722

1

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

1

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

1

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

add a comment |

1

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

1

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

1

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

Yeah you were right about passing the searchBar as a props, not state, after doing so and putting it in the componentDidMount function it works great. So what is better? using getInititialProps for props that appear to the user all the time and use componentDidMount when you want to fetch data that the user doesn'r see first? Or just fetch everything in getInitialProps without the componentDidMount part?

– Contentop
Jan 4 at 1:05

The former. For example, I have a product page which needs to be rendered server side for optimal user experience and SEO. But I only need the main data to be available in order to render the page (price, image, basic shipping). That would go in getInitialProps. But secondary widgets, especially if they are below the fold, can have their data fetched on component mount.

– Avremel Kaminetzky
Jan 4 at 1:43

At the end of the day you are making a tradeoff: Do you want the page to do more server side fetches and no loading spinners? Have everything fetched in getInitialProps. If you are fine with loading spinners for some things, fetch client side.

– Avremel Kaminetzky
Jan 4 at 1:47

add a comment |

draft saved

draft discarded

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu