React container component to fetch paginated data for a stateless table component
Question 1
  
  Is this all reasonable?


Absolutely!


  Question 2
  
  I noticed that the component will re-render when it receives a new
  currentPage and then re-renders again, once the data is loaded. The
  first re-render is not necessary as nothing changes before data is
  actually loaded. Should I just live with this or should I implement
  shouldComponentUpdate() to check if data has changed. Or is that
  potentially even more costly than the re-render itself?


This is normal, and I wouldn't worry about it. In fact, not having to worry about these types of things is a major goal of React. 

It's important to realize that re-renders in React only update the DOM when there are changes and only update the relevant DOM nodes. DOM operations are very time consuming, because DOM objects are incredibly heavy objects, and updates have knock-on effects. This is one of the main reasons React doesn't use DOM objects internally. Instead, it uses a virtual DOM. Through a process called reconciliation, React can update the real DOM from the virtual DOM incredibly fast. 

In the state where the page changes, but you don't have data yet, React will call render(), very quickly realize there are no changes to the element tree, then stop - this probably happens in roughly a millisecond.

On that note, you do need to be careful when you use Redux - specifically react-redux / connect(). Try to keep mappings of state to props as minimal as possible – don't map an entire object from the Redux tree to a prop for a component if you only need one property of that object. The reason this is important, is because:


Your reducers generate new objects every time they run (if you're using them correctly)
Redux and React use JavaScript's default comparison when deciding if it should update a component
Every object is distinct in JavaScript, even if their structure is identical


So a reducer takes one object, then generates a new object, and even if the properties of these objects are exactly the same, React/Redux will treat it like a change and update components. This is OK for one component, but if you make this a habit your application, you'll be missing out on one of React's biggest features: performance.



// Do this:

const GoodComponent = (props) =&gt; `page number: ${props.page}`;

connect(state =&gt; {
  page: pagination.page
})(GoodComponent)


// ... not this:

const BadComponent = (props) =&gt; `page number: ${props.pagination.page}`;

connect(state =&gt; {
  pagination: pagination
})(BadComponent)





  Question 3
  
  Is using componentDidUpdate() to check if currentPage has changed and
  then re-load the data a good way of controlling the load process?


Absolutely - this is probably why componentDidUpdate() was created.


  Question 4
  
  Is building the URL this way acceptable?
  
  const pageParam = currentPage ? "?_page=" + currentPage : "";
  fetch('https://jsonplaceholder.typicode.com/posts/' + pageParam)


It's probably OK for now, although you could use template literals. I generally avoid constructing the query string manually, except for the simplest cases. This is because the second you have multiple query params and some of them are optional, the construction gets tricky – what adds the question mark? how to handle trailing ampersands? trailing question mark?. Instead, use the URL API's searchParams property. Or, find a library that gives you more conveniences, like being able to provide query params as a dictionary/object in fetch()'s second argument.