Defining state is done by using class fields, a fairly new feature of JS, that's enabled via Babel since it isn't fully official yet. (See https://github.com/tc39/proposal-class-fields for the proposal, which is at Stage 3, meaning that it's one step away from being officially adopted.) With older JS versions, you would have had to create this.state in the class constructor, but this syntax is clearer. Let's remember what the code looked like, and let's drop the Flow definition.

First, let's modify the RegionsInformationTable component:

export class RegionsInformationTable extends React.PureComponent<...> {
    state = {
        countries: [
            { code: "AR", name: "Argentine" },
            { code: "BR", name: "Brazil" },
            { code: "PY", name: "Paraguay" },
            { code: "UY", name: "Uruguay" }
        ],

        regions: []
    };

Second, let's see what happens when a country changes. Rendering for an object can depend on both its props (which it cannot change, as we said) and its state (which it can change), but there is an important restriction on updating state. You cannot simply assign a new value to the component's state because it won't be detected by React, and then no rendering will be done. Instead, you must use the .setState() method. This method can be called in different ways, but functional .setState() is the safest way to do this. With this, you must pass a function that will receive both state and props and return whatever parts of the state need to be updated. In our earlier code, we would have written the following:

update(country: string) {
        .
        .
        .
        this.setState((state, props) => ({ regions: [ 
                .
                .
                .
            ]}));

If you check, you'll see that we didn't include the state and props parameters in the actual code, but that was in order to satisfy ESLint's rule about no unused arguments in functions.