part 9 updates

Author: mluukkai

src/content/0/en/part0a.md

@@ -340,12 +340,12 @@ Despite changes *all the submitted exercises remain valid*, and the course can b
 
 Recent major changes
 
+- Part 9 (12th August, 2024): ESLint configurations updated
 - Part 3 (20th June, 2024): ESLint configurations updated
 - Part 10 (21st March, 2024): Create React app replaced with Vite
 - Parts 3-5 (February-March 2024): Libraries used for testing changed
 - Part 10 (26th February, 2024): Library versions updated
 - Part 11 (16th January 2024): Example project dependencies updated
-- Parts 1-2, 5-9 (11th September - 5th October): Create React app replaced with Vite
 
 ### Expanding on a previously completed course
 

src/content/0/fi/osa0a.md

@@ -282,12 +282,12 @@ Kurssilla ei ole enää vuosittaisia versiota. Kurssi on siis käynnissä koko a
 Muutoksista huolimatta <i>kaikki jo tehdyt palautukset säilyvät voimassa</i>, eli voit jatkaa kurssia päivityksistä huolimatta normaaliin tapaan.
 
 Viimeaikaisia isompia muutoksia
+- Osa 9 (12.8.2024): ESLint-konfiguraatiot päivitetty
 - Osa 3 (20.6.2024): ESLint-konfiguraatiot päivitetty
 - Osa 12 (21.3.2024): Create React app korvattu Vitellä
 - Osat 3-5 (helmi-maaliskuu 2024): Testaukseen käytetyt kirjastot muutettu
 - Osa 10 (26.2.2024): Kirjastoversiot päivitetty
 - Osa 11 (16.1.2024): Esimerkkiprojektin riippuvuudet päivitetty
-- Osat 1-2, 6-9 (11.9-5.10.2023): Create React app korvattu Vitellä
 
 ### Aiemmin suoritetun kurssin täydentäminen
 

src/content/10/en/part10a.md

@@ -7,9 +7,6 @@ lang: en
 
 <div class="content">
 
-Note: This course material was updated in Feb 2024. Some updates are not compatible anymore with older material.
-We recommend a fresh start with this new Part 10 material. However, if you´re returning to this course after a break, and you want to continue the exercises in your older project, please use [Part 10 material before the update](https://github.com/fullstack-hy2020/fullstack-hy2020.github.io/tree/e9784f36de8a0badc28fabde49e33e2959479177/src/content/10/en).
-
 Traditionally, developing native iOS and Android applications has required the developer to use platform-specific programming languages and development environments. For iOS development, this means using Objective C or Swift and for Android development using JVM-based languages such as Java, Scala or Kotlin. Releasing an application for both these platforms technically requires developing two separate applications with different programming languages. This requires lots of development resources.
 
 One of the popular approaches to unify the platform-specific development has been to utilize the browser as the rendering engine. [Cordova](https://cordova.apache.org/) is one of the most popular platforms for building cross-platform applications. It allows for developing multi-platform applications using standard web technologies - HTML5, CSS3, and JavaScript. However, Cordova applications are running within an embedded browser window in the user's device. That is why these applications can not achieve the performance nor the look-and-feel of native applications that utilize actual native user interface components.

src/content/9/en/part9.md

@@ -12,7 +12,7 @@ In this part, we will be using the tools previously introduced to build end-to-e
 
 This part is created by [Tuomo Torppa](https://www.linkedin.com/in/tuomotorppa), [Tuukka Peuraniemi](https://www.linkedin.com/in/tuukkapeuraniemi/) and [Jani Rapo](https://www.linkedin.com/in/jani-rapo-5520817b/), the awesome developers of [Terveystalo](https://www.terveystalo.com/fi/Yritystietoa/Terveystalo-tyontantajana/Digital-Health/), the largest private healthcare service provider in Finland. Terveystalo’s nationwide network covers 300 locations across Finland. The clinic network is supplemented by 24/7 digital services.
 
-<i>Part updated 5th October 2023</i>
-- <i>Create React App replaced with Vite</i>
+<i>Part updated 12th August 2024</i>
+- <i>ESLint configurations updated</i>
 
 </div>

src/content/9/en/part9e.md

@@ -252,10 +252,13 @@ If we take a closer look at the data, we can see that the entries are quite diff
 }
 ```
 
-Immediately, we can see that while the first few fields are the same, the first entry has a *discharge* field and the second entry has *employerName* and *sickLeave* fields.
-All the entries seem to have some fields in common, but some fields are entry-specific.
+Immediately, we can see that while the first few fields are the same, the first entry has a *discharge* field and the second entry has *employerName* and *sickLeave* fields. All the entries seem to have some fields in common, but some fields are entry-specific.
+
+When looking at the *type*, we can see that there are three kinds of entries:
+- *OccupationalHealthcare*
+- *Hospital*
+- *HealthCheck*
 
-When looking at the *type*, we can see that there are three kinds of entries: *OccupationalHealthcare*, *Hospital* and *HealthCheck*.
 This indicates we need three separate types. Since they all have some fields in common, we might just want to create a base entry interface that we can extend with the different fields in each type.
 
 When looking at the data, it seems that the fields *id*, *description*, *date* and *specialist* are something that can be found in each entry. On top of that, it seems that *diagnosisCodes* is only found in one *OccupationalHealthcare* and one *Hospital* type entry. Since it is not always used, even in those types of entries, it is safe to assume that the field is optional. We could consider adding it to the *HealthCheck* type as well since it might just not be used in these specific entries.
@@ -272,8 +275,7 @@ interface BaseEntry {
 }
 ```
 
-If we want to finetune it a bit further, since we already have a *Diagnosis* type defined in the backend, we might just want to refer to the code field of the *Diagnosis* type directly in case its type ever changes.
-We can do that like so:
+If we want to finetune it a bit further, since we already have a *Diagnosis* type defined in the backend, we might just want to refer to the *code* field of the *Diagnosis* type directly in case its type ever changes. We can do that like so:
 
 ```js
 interface BaseEntry {
@@ -417,7 +419,7 @@ const parseDiagnosisCodes = (object: unknown): Array<Diagnosis['code']> =>  {
 
 Now that our backend supports adding entries, we want to add the corresponding functionality to the frontend. In this exercise, you should add a form for adding an entry to a patient. An intuitive place for accessing the form would be on a patient's page.
 
-In this exercise, it is enough to **support *one* entry type**. All the fields in the form can be just plain text inputs, so it is up to the user to enter valid values.
+In this exercise, it is enough to **support one entry type**. All the fields in the form can be just plain text inputs, so it is up to the user to enter valid values.
 
 Upon a successful submission the new entry should be added to the correct patient and the patient's entries on the patient page should be updated to contain the new entry.