WIP Elm Calendar Library

Current Status

This library has only just been born, so it's in a somewhat sophomoric state.

API Design Considerations

See: http://package.elm-lang.org/help/design-guidelines

What concrete problem does this library aim to solve?

Web application authors using Elm currently have the following options when tackling requirements involving interactive calendar functionality:

• A JavaScript library (such as FullCalendar) through ports
• Using a WIP, yet to be published Elm library such as Elm Calendar
• Writing their own calendar implementation

These options all have their drawbacks when compared with a hypothetical 'production-ready' Elm library.

Ports seem to be a much less natural interface for an Elm app to integrate with than a triplet of model, update, and view functions.

Elm Calendar provides some good core functionality, however it doesn't seem ready for publication and hasn't been under active development for about 9 month.

I think that writing their own calendar is a reasonable option for any Elm developer working on a production app.

This library aims to satisfy the core requirements for most Elm apps that need interactive calendar behaviour

What will it mean for this API to be a success?

Success could take a number of forms:

• When I can use this library in my own projects
• When others are able to make use of this library
• When others contribute their expertise such that this library becomes worthy of publication and a pleasure to use

Who has the problem this library solves? What do they want from an API?

I have this problem. I'd like:

• a pleasantly simple API for basic use cases (such as widgets that don't require drag & drop - the interface for these should be dead simple);
• an understandable and flexible API for full-featured interactive calendars;
• to confidently rely on the correctness of the implementation, regardless of domain or locale; and
• to add calendars to my apps without a particular architecture (outside of TEA) begin imposed on me.

What specific things are needed to solve that problem?

A Calendar should provide:

• Multiple modes, able to be used independently or in combinations
• Display of events, with a simple way to customize the layout and style
• Interactive creation, alteration, and removal of events
• Support for recurring events
• Integration with other calendars (e.g. Google Calendar)

In order to do this, a consumer's events must have:

• An id - implemented, but currently as a string
• A label - implemented
• A start time - implemented
• A finish time - implemented
• A description - not yet implemented
• A recurring schedule - not yet implemented

Have other people worked on this problem?

What lessons can be learned from them? Are there specific weaknesses you want to avoid?

FullCalendar is featureful, but it's not in Elm! Shouldn't Elm have a super sweet calender library of it's own?

TODO: Summarise design choices I'm making differently to FullCalendar.

Elm Calendar looked promising, but is still in a WIP state and hasn't been touched in a long while. I would rather start from scratch so that I can make my own design decisions and understand the code from the ground up.

Feature Progress

Daily Mode

• Layout
• Previous & next day buttons
• Today button
• Event display
• Drag to extend finish time of event
• Drag to reschedule event
• Appropriate cursors for different event drag modes
• Change to a grabbing cursor when moving or extending
• Add new events (button)
• Remove events
• Drag to add new events
• Keyboard shortcuts:
  • See all shortcuts: ?
  • Change your calendar view to the next date range: j or n
  • Move to the current day: t
  • Create a new event: c
  • Delete an event: Backspace or Delete
• Display: deal with overlapping events
• Remove event confirmation

Other keyboard shortcuts not yet applicable:

• Day view: 1 or d
• Week view: 2 or w
• Month view: 3 or m
• Custom view: 4 or x
• Agenda view: 5 or a
• See an event's details: e
• Refresh your calendar: r
• Move to add a calendar section: +
• Put your cursor in the search box: /
• Go to the Settings page: s
• Undo: z
• Save event (from the event details page): ⌘ + s (Mac) or Ctrl + s (Windows)
• Return to calendar grid from an event details page: Esc

Weekly Mode

Not yet started. Should be able to leverage much of the behaviour implemented for Daily mode.

• Mode switching

Monthly Mode

Not yet started.

Yearly Mode

Not yet started.

Library

• Untangle msg/Msg mess
• Impose some semblence of sanity on the module structure
• Tinker with various options for exposing configuration
• Research trade-offs with different approaches to exposing CSS and layout customization

License and Copyright

Copyright 2018 Flux Federation, MIT license.

This software was written by Kieran Trezona-le Comte, with the initial implementation done during the Flux Federation monthly 'hack days'. You can check out other useful stuff from Flux here on Github.