Components talk to each other. So far that has worked in two ways: parameters down, EventCallback up. That is enough for most cases, but not
for all. In this lesson, two more ways come in: cascading values and a state service. Then components talk to the browser. The calendar
creates an appointment and puts the focus on the new entry, through a small TypeScript module. And the filter script from module 2.2, which
has been waiting since lesson 2.5.4, moves into the Blazor contact list. Along the way you meet the catch that lesson 2.2.4 announced: Blazor
switches pages without reloading them.
Data down, events up
The rule from lesson 2.5.8 remains the most important: A component gets what it shows as a parameter from its parent, and it reports what has
happened through an EventCallback. What follows from that is up to the parent. That’s how WeekSwitcher knows no weeks, and the calendar
knows no buttons.
In this lesson, the calendar gets a small form for new appointments, NewAppointmentForm. It creates the appointment and reports it upward:
<NewAppointmentForm FirstDay="Week" Zone="zone" OnCreated="ShowCreatedAsync" />
The form doesn’t know that it sits in a calendar. It gets a day to begin with, the office’s time zone and a method of its parent. What is
visible after the appointment is created is for the calendar to decide in ShowCreatedAsync.
Two cases don’t fit this pattern:
- Many components far below need the same value. Passing it down as a parameter through every level makes every component in between a messenger for something it doesn’t need.
- Two components without a common parent should learn of each other, such as two islands on a page.