Answers

answers.js

//ANSWER ======== A

/* Notes:
  https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
  Here we can find in which cases we should expect a catch to be raised in the promise and when not. Seems like unless
  there is a problem with the connection or bad formed url, we should expect an error to not be raised. Just an status code that reflects that
/*

const urls = [
  "http://randomurl.com/subpath1",
  "http://randomurl.com/subpath2",
  "http://randomurl.com/subpath3"
];

function statusChecker(response) {
  // https://developer.mozilla.org/en-US/docs/Web/API/Response
  if(response.ok){
    return response;
  } else {
    throw Error(response.statusText);
  }
}

async makeRequest(url) {
  try {
    const response = await fetch(url)
    return statusChecker(response)
  } catch(e) {
    console.error("Error", error)
  }
}

//ANSWER ======== B

/*
  So basically I think it's a bad practice dealing with sync stuff in general because that would lead to blocking
  the thread doing I/O operations.
  Not only that but from a user perspective it's really ugly to see that the screen is stuck because some background
  stuff is being performed.
  It would be much better to handle the state of this so while the async operation is being handled, there is a loading status
  to which we react in the UI by showing a user-friendly message.
  ample of this in react would be something like the following code
/*

{loading ? <FancySpinner/> : <RenderFileContent>}

//ANSWER ======== C

/* Notes plus answer
  https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108
  https://medium.com/@mustafa.abdalmogoud/how-the-browser-renders-html-css-27920d8ccaa6
  
  We can see there how the rendering in the browser takes places.
  Layout is the second stage within the 4 steps for rendering things in browser. So if something changes in the layout
  will affect it's children.
  Something like translations don't affect layout so they are take place in the last stage of the rendering proces making
  everything way smother and performant.
  To make sure there is a performance issue the easiest way would be to have an slow device like an old mobile phone to
  make sure resources are relevant at that point with regards to producing the error
*/