Clarify external interface behavior a bit

Author: SebastianAigner

Building Web Applications with React and Kotlin JS/03_A_First_Static_Page.md

@@ -102,7 +102,7 @@ Type or paste the above code as the contents of your `render` call. If IntelliJ
 
 While writing HTML in Kotlin just for the sake of it is a noble idea, there are actually a lot more benefits to writing your HTML directly inside Kotlin. A big advantage of using this domain specific language is that we can manipulate our website content using language constructs we are already familiar with. Whether it's conditions, loops, collections, or string interpolation, we can expect them to work the same in HTML as they would in Kotlin.
 
-Now, instead of hardcoding the list of videos, let's actually define them as a list of Kotlin objects and display those objects instead. We'll create a simple data class to hold together the attributes of a video called `KotlinVideo` (we can do this in `Main.kt` or a file of our choice). We will also define a corresponding `external interface` – more on that later.
+Now, instead of hardcoding the list of videos, let's actually define them as a list of Kotlin objects and display those objects instead. We'll create a simple data class to hold together the attributes of a video called `KotlinVideo` (we can do this in `Main.kt` or a file of our choice). We will also define a corresponding `external interface`, which will prove valuable at the point where we get real data, from a real API.
 
 ```kotlin
 external interface Video {

Building Web Applications with React and Kotlin JS/08_Using_an_External_REST_API.md

@@ -59,7 +59,7 @@ import kotlinx.browser.window
 import kotlinx.coroutines.*
 ```
 
-Let's look at what's happening in this *suspending function*. We `fetch` a video from the API given an `id`, wait for it to actually be available, turn it into a JSON, wait again for the completion of that operation, and return it, cast as a `Video` Kotlin object.
+Let's look at what's happening in this *suspending function*. We `fetch` a video from the API given an `id`, wait for it to actually be available, turn it into a JSON, wait again for the completion of that operation, and return it – but before, it casts it to the `external interface Video`, which we defined in an earlier chapter. You will see a warning for this unchecked cast – but this is in the nature of using a JavaScript definition like `fetch`: The compiler _can't know for sure_ that what we get back is actually an instance of `Video`. The compiler just needs to trust the developer on this.
 
 A function call like `window.fetch` returns a `Promise` object. We would have to define a callback handler which gets invoked once the `Promise` is *resolved* and a result is available. However, since we are using coroutines in our project, we can `await` those promises. We're writing code that looks sequential but remains non-blocking. Whenever a function like `await()` is called, the method stops its execution (it *suspends*, hence the keyword). It continues execution once the `Promise` can be resolved.