This chapter will be the most involved in the book. Throughout the book, there have been minor to not-so-minor differences between chapters. These are intended so that if you meet a fork in the road, this book offers coverage to both options. The chapters are intended to be complementary, instead of hitting the same note all the time. Here, we will not be revealing much more about core ReactJS, but show how to engage a problem with the thorniness of real-world business problems, and a solution that engages ReactJS but is not focused on it. We will be engaging ReactJS on a more serious application, a calendar with support for recurring events that offers more sophistication and power than, for instance, Google Calendar, as seen in the upcoming figures. If you have a 7:00 PM second and fourth Thursdays each month Toastmasters' Club meeting, it's supported! The core functionality is very much intended not to be a mere toy.
In this chapter, we will discuss the following points:
- Learning about calendars with repeating calendar entries
- The nuts and bolts for a class and its Hijaxed form
- The basic data types—plain old JavaScript objects
- A rendering function—an outer wrapper
- Rendering the page—a one-time calendar entry UI
- An expanded user interface for recurring calendar entries
- Rendering calendar entries—anonymous helper functions
- The main loop for displaying calendar entries
- Sorting each day's calendar entries for display
- Supporting Markdown in calendar entry descriptions
- Working on one main component at a time
The following is a sample screenshot showing how you enter a repeating entry in Google Calendar:
This calendar system is inspired by a private calendar system that uses regular expressions matched against a date string, like this: Wed Apr 29 18:13:24 CDT. Also, there is really quite a lot that can be done with the power of regular expressions. An entry to check car engine fluids, for instance, every first Saturday of even-numbered months, is periodic_Sat.(Feb|Apr|Jun|Aug|Oct|Dec).( 1| 2| 3| 4| 5| 6| 7)..................,Check fluid levels in car. This, however, is nothing compared to the hairy beast of a truly complex regular expression. But it does give a hint on why regular expressions are considered write-only code. It may be guessed that even if you are a regular expression writer, you put off checking until later (if you have to). In other words, you don't want to check whether the regular expression quoted earlier in this paragraph matches the date for the first Saturdays of even-numbered months. This is the effect that regular expressions have on programmers, and this regular expression is elegant compared to a URL regular expression, which begins like this:
~(?:[a-zd.-]+://[^<>s]+|(?:(?:(?:[^s!@#$%^&*()_=+[]{}|;:'The code in this chapter is intended to be readable, at times slowly and laboriously, but very clearly without a trace of regular expressions. It has been said that a programmer has a problem with strings, and says, "I know! I'll use regular expressions!" Now the programmer has two problems.
In my own experience, I've been using regular expressions for years, and they are by far, byte for byte, my most effective defect injection method, and I often get simple regular expressions wrong the first time. This is why I'm following others in deprecating regular expressions as Not a Good Part.
The program, by default, presents a relatively simple user interface for entering one-time calendar entries.
Here is a screenshot of our program's user interface as it is initially presented, without a drill-down into the smorgasbord of options for repeating calendar entries:
Progressive disclosure reserves a more detailed combination of supported items for recurring calendar entries, with added controls for repeating calendar entries displayed if a user opts to see them.
The following is a screenshot of the more advanced interface for recurring calendar entries. Because there are several different ways in which recurring calendar entries are often organized, several controls are available.
