Schedule Conflict Block

• 

  Initial launch of block into Settings menu

• 

  Field selections are limited to only relevant types

• 

  Linked table is picked up automatically from Field selection

• 

  "Done" button is disabled until all required fields are selected

• 

  A View must be selected for the block to monitor for conflicts

• 

  Conflicts are displayed as record cards and grouped under the parent "Person" or "Item" being scheduled

• 

  Event/Booking Record cards can be clicked to expand, and the name of the Person/Item can be clicked to expand the record

Inspiration

Building booking systems for clients in Airtable always presented unique challenges - the biggest of those being the prevention of double-booking or conflicting event scheduling. Often, the solution was to export data from Airtable into some other tool for processing, and then bring it back in. This was both inelegant and brittle. Custom blocks present a perfect opportunity to provide this functionality within the same context as the Airtable data.

What it does

This block will watch a view in a table that is meant for scheduling/booking people or items from another table and determine whether a person or item has been scheduled or booked for overlapping time slots, thus bringing visibility to conflicts in scheduling before they cause problems.

How I built it

I used the 'Hello World' JavaScript template provided by Airtable as a starting place, and primarily used Airtable's SDK and vanilla JavaScript/React.js. I brought in styled-components to help with some :hover functionality, because I knew the CSS I could use for that, but couldn't quite see how to emulate the same with React's JSX and Airtable's SDK. Other than that, there are no other libraries used.

The structure of the block source is fairly straight-forward, requiring only a few functional components. The only use of state required was to track the progress and status of the settings menu. After that, all input from the user is stored in Airtable's very handy globalConfig.

Challenges I ran into

I didn't have a ton of experience working with Dates in JavaScript, so figuring out how to finagle those into just what I needed for comparisons was a unique challenge for me. And, of course, figuring out the algorithms required to capture all the possible types of overlap between two date ranges took some trial and error.

The biggest challenge, I think, was figuring out how to build the Settings menu in the most intuitive way. I knew I wanted to try to eliminate as many "bad" selections as possible, but figuring out how to do that in a user-friendly way was interesting. In my first iteration of the block, I had one spot where I would throw an error message in a modal if a certain rule was broken; but in the end, I believe I was able to come up with an intuitive flow that prevents the user from being able to make any "bad" selections at all. It required storing/clearing globalConfigKeys, and re-rendering the menu on any selection, passing in the new keys that were stored/cleared. I was worried about performance with that sort of constant re-rendering, but I was pleasantly surprised at how snappy Airtable's SDK, and React performed!

Accomplishments that I'm proud of

I had very little experience with React.js prior to the launch of the Custom Blocks beta, and I'm a fledgeling developer in all respects, so I'm very proud to have been able to build anything at all, much less what I feel to be a well-polished, functionally solid, and extremely useful plugin for a fairly wide-range of scheduling or booking use-cases. I'm beyond pleased that this Block has already proved to be a useful addition for my clients.

What I learned

I learned so much about using React -- I think I am finally getting a solid grasp on concepts like state, props, and the passing of props down through child components. And I have definitely developed an understanding of, and a great appreciation for the benefits of componentized development... see the "what's next" below.

What's next for Schedule Conflict Block

Refactoring! Now that I am understanding better what it means to componentize an app's architecture, I am realizing how much clean-up and reorganizing I can do to make my block easier to expand on in the future, and more resilient overall. I have a few functional components in the main index.js file that I need to spin off into discrete component files (a project I got started in my most recent PR). I have blocks of logic that I need to encapsulate into modular functions. And I'm sure there is plenty of styling that could be done more efficiently!

After that, I plan to gather some feedback from clients to see if there are ways I could make my block more flexible in terms of setup. Right now it requires a pretty specific set-up -- although, it may just be that the nature of detecting scheduling conflicts relies on that structure. In any case, I don't want to add any more major functionality to this block, as is -- I want to keep it simple so as to be capable of fitting into a wide range of workflows, as many of Airtable's own blocks do.

However, I do have a thought to spin-off a new block, based on this one, that could serve as a full-service "applet" for scheduling and booking workflows -- something that can provide real-time feedback on scheduling based on user-input, and serve as a central place for creating the events or booking records directly. This sort of tailored functionality necessarily reduces flexibility, but I think the broad concepts of creating events or booking records could be captured in a useful little Custom block as well!

Built With

• airtable/blocks
• javascript
• react
• styled-components