Recently, I have been working on an interactive Lectionary Browser. A lectionary, in case you do not know, is a collection of scripture readings used in the planning of Chrisitan worship in some Christian communities. The most common lectionary is the Revised Common Lectionary, which is the focus of my little app.
The RCL consists of a three-year cycle. Each year contains a year's worth of readings for every Sunday of the Christian Year and also some special days. And each day is part of a particular season that corresponds to the time of the year. The seasons are the same every year, but the readings for each day are different.
The RCL names it's years with a complete lack of creativity. The first year is named "Year A." Guess what the others are called? Year B and Year C! So clever. But they are somewhat thematic as each year tends to focus on one of the synoptic Gospels (Matthew, Mark and Luke) and all of the years turn to John for special days.
The seasons used by the RCL are Advent, Christmas, Season After Epiphany, Lent, Easter, and Season After Pentecost. The Season After Epiphany and the Season After Pentecost are somtimes referred to as "Ordinary Time" but the use of the word "ordinary" is confusing. It does not mean that they are dull. Rahter, it means they are "ordered" or "ordinal" and thus follow the pattern prescribed by the lectionary.
For my app, I first created a Ruby on Rails back end that served as an API for the lectionary readings. My application supports muliptle lectionaries, though I only modeled the RCL. In the future, I could add additional lectionaries easily. The Lectionary Browser also provides a RESTful interface, so resources are found via logical URL structure. All requests made to the RESTful API are responded to with standard JSON responses.
For the frontend of my app, I wrote a React app that uses Redux for state management. Redux was the most difficult part of this project for me because it is conceptually a little complex, but as I build the app and started using it in a real application, I started understanding how it works.
I made a nice video to show you how the app is supposed to work:
The hardest part of this project for me was getting my head around Redux and how it is supposed to work. Redux is a tool for managing state, which is something React does natively, but the React model is somewhat limiting. With Redux, you can provide pieces of your state to your components as you need to from a centralized store where all your state is stored. In order to accomplish this, the Redux packing provides tools for creating your store and manipulating it. Another package, called "react-redux" makes Redux integrate nicely with your React components by connecting them to your Redux store - with a function cleverly called "connect."
Once you have your components thought through, and the data they will need discerned, you can connect them to your Redux store and retrieve the data you need for that component. Changes can be made, but you have to be careful that you don't mess up your state, so Redux uses Actions and a Dispatch function that manages your changes to your state. Your actions are simple functions that describe your changes, and dispatch is a function provided by Redux that safely updates your state. While it sounds complicated, and it is a bit, it actually makes state management much simpler.
I hope to continue working on this project, adding a user model and note taking capability among other features. So, perhaps, if I find time, I will make this app more useful.