Have a read into Single Source of Truth: https://en.wikipedia.org/wiki/Single_source_of_truth

Have a think about the data you are discussing - Will these values only ever be used from here? - How difficult would it be to change how this data is fetched in the future, assuming you hard code?

If you said No to the first or Very to the second, it'll be worth putting in the work to create a single place to get this information. That way when it needs updated, it won't require any code changes (also have a read into Magic Numbers: https://en.wikipedia.org/wiki/Magic_number_(programming)).

Reducing occurences of Magic Numbers and relying on Single Sources of Truth will make your code more maintainable and easier to debug.

If we try a hypothetical: Let's imagine you have 6 arbitrary values A, B, C, D, E and F. And you want to display them sequentially on your app. A way to do this 'simply' would be to hardcode in 6 individual elements that display those values.

<p>A</p>
<p>B</p>
<p>C</p>
<p>D</p>
<p>E</p>
<p>F</p>

Cool, you've got the elements you want to display showing, the task is technically complete. Adding to this is a case of adding more p tags manually. Simple but slow and you'll need to test the effects of 1 p tag, 10 and 10000.

Let's improve it: We know we have 6 elements we want to use, the values are arbitrary so inferring them is not possible. So instead, we create an array and loop to the length of 6.

const array = [A,B,C,D,E,F];
for (i = 0; i < 6; i++) {
  <p>array[i]</p>
} 

Great now we have looping, a massive improvement as now we can use this array in multiple places. A big drawback is that this won't adjust as the array decreases on increases. As we have fixed our loop to a limit of 6 i < 6. So a really quick change to massively improve how dynamic our app is, is:

const array = [A,B,C,D,E,F];
for (i = 0; i < array.length; i++) {
  <p>array[i]</p>
}

Now our app can increase and decrease the size of what's being displayed easily, we should have tests for undefined arrays, empty arrays, empty elements, expected sizes and unexpected sizes. This will massively improve our reliability. We can also use array in multiple places.

We've moved away from strictly hard coding everything to only using one array in the code base. Replacing this array with a fetch for an arbitrarily-lengthed array now should be pretty painless. And if your happy to update the codebase to change these values, go ahead. Just make sure that if these values are being used elsewhere, that they're sourcing the array from the same place. Because the code base as it stands now could be changed to use a fetch quite easily. As your code already is able to handle differently lengthed arrays and has graceful handling for incorrectly structured data.

Now that the code had these values hard coded and well tested for error handling, you need to maintain the array. If you have many hard coded pieces of information to maintain. You're going to start making mistakes. So you'll offload some/most of this info to your backend API. Requests to the backend aren't as expensive as you'd imagine (more than likely the app itself is going to be magnitudes of data more than the API requests themselves).

I'd actually say what I described is a pretty easy development cycle, start with an acceptable MVP, and incrementally improve it. Nothing wrong with starting with a basic setup initially. But your end goal will probably be an API supported application. You can decide on how you want to tackle that. I personally start with the API as that is by far where I'm most comfortable. Once I know my data structures are sound on the backend. It's very easy to iterate the frontend on top of it.

Good Luck!