Recently I've created javascript calendar component called Kalender. What the hell was I thinking in creating yet another javascript calendar?
Javascript has a lot of frameworks and libraries. Sadly a lot of them are not up to my personal standards. This is probably because about every developer seems to be writing Javascript. This includes junior developers and developers who mainly use another language and bend their style only enough to get things working. Besides that front-end development is a rapidly changing environment with browsers, frameworks and requirements changing fast, what used to be best practice is now frowned upon.
Most of my professional time is spent working on client projects. Clients expect me to deliver business value as effectively as possible which often means writing code that is good enough and using existing libraries, even if these libraries are not what I'd like them to be.
When problems arise I curse, fix and work around them and go on delivering business value. This year I ran into trouble concerning localization using a date range picker.
The main cause of the problem is the use of Javascript's Date object which includes both time and localization and are outside the scope of an actual date which is only just a specific day. Javascript's Date object should have been called Time. The date range picker in question also returned Javascript Date objects.
The concept of time should be excluded when picking a date. For bigger web applications I also want to handle localization somewhere else, not in every single component separately. This made me decide to write my own datepicker. There is no urgent need for another datepicker but I now have one which suits my needs.
My implementation is mainly inspired by Calendar Base which comes closest to my needs. Furthermore I was also looking for an opportunity to exercise in creating a component in a functional coding style.
My most important requirement for any given component is that it should be maintainable. For me this means that it should be (in order of importance); clear, tested, modular and have a minimal amount of dependencies. Note that I'm easily inclined to prefer maintainability over performance. It should be just fast enough.
Documentation is good, clear examples are better but having a clear understanding of the code is the best. Being able to understand a whole codebase gives a clear view of it's usage and possibilities for implementation, modification and extensibility.
Understanding other peoples code is hard. Naming well and applying a good coding style helps with code clarity.
Important constraints of a good coding style are therefore not so much concerned with things like formatting but rather with constraints like maximum number of arguments or statements in an expression. It forces clarity of concepts and intentions.
Some good resources on this topic are Code Complete and Refactoring. For Javascript development look into JSCS.
Tested code not only has less bugs, it's biggest advantage is it allows you to easily refactor code while not introducing new bugs. This extends into clarity and modularity, as a codebase grows you'll want be able to easily split things up.
Tests are far more important for code at the center of your application and less for the code at the edge of the domain. Browser integration tests are not worth it as they are expensive to create and maintain. The corresponding code tends to change often. When building UI components you should always play with the actual implementation anyway, you'll get a much better feel of the quality.
Modularity is about designing boundaries and communicating concepts. About what does and does not belong together. Modules alone should do little but encourage reuse and collaboration.
Kalender only renders one calendar month. You pass it a year and a month, it returns a matrix containing all the days for that month. It does not to include functionality for date selection as it's not something specific to a calendar.
This is hard, I'm often not really sure about what to include or exclude. For now date selection is handled in the example datepicker implementations but I imagine adding a separate events module to Kalender when also adding support for date ranges.
Dependencies are a common problem when trying to get things running and make projects hard to maintain. This applies even more so to legacy or multi-language, multi-dependency manager projects. Consider just copying over libraries instead, having everything directly available.
Choosing dependencies is often a trade off; throw in one more handy library or potentially run into trouble later down the road. Don't use fancy languages like Coffeescript to compile to javascript. It forces others to learn yet another trending language.
There are exceptions to this rule; use current day technologies like es6 and the Babel transpiler to provide backwards compatibility. Also dependencies for hinting and style guides are fine as these dependencies are not required to get the project running.