DEV Community: Michel Billard

A decimal calendar is a terrible idea

Michel Billard — Wed, 09 Nov 2022 16:02:00 +0000

I was thinking about a decimal clock as totally normal people sometimes do and eventually ended up doing some research about a decimal calendar.

Why is a decimal calendar a terrible idea

You're probably aware that a year has 365 days (or 365 days, 5 hours, 48 minutes, and 46 seconds to be more precise) which is not easily divisible by 10.

Do you divide the year into 10 months of ~36 days? Do you then have 10 weeks of 3.6 days? Or 3 weeks of 10 days? You could keep the 12 months (which doesn't really make it a decimal calendar, does it?) each with 3 weeks of 10 days. You then need a special week at the end of the year for the extra 5 (or 6) days.

Either way, a decimal calendar is way too impractical and not a good idea.

What about other calendar systems?

Now that we can work with. Throughout my research (which consisted of this Wikipedia page about the calendar reform) I found two interesting proposals. The World Calendar and the International Fixed Calendar which are both perennial calendars, meaning they don't change year to year. November 9 is always a Thursday on the World Calendar and a Monday on the International Fixed Calendar.

Finding what today is on those calendars

That got me thinking about how you could figure out where a specific date landed on one of those two calendars and then I went coding.

The gist of it is quite simple:

Calculate which day of the year we're at (ex: 200th day)
Calculate which date corresponds to that day on the other calendar

There are some quirks to workaround obviously since those calendars still have to deal with leap years and both have an extra day at the end of the year because 365 days is still not divisible in nice regular chunks.

For the International Fixed Calendar the logic is relatively simple (this code doesn't include the logic for the leap year):

// diffDays is the number of days since the beginning of the year
const dayNumber = (diffDays % 28) + 1;
const dayName = WEEKDAYS[diffDays % 7];
const monthName = MONTHS[Math.floor(diffDays / 28)];

For the World Calendar it's a little more complex because some months have 31 days and others 30 days. So the logic goes like this:

Find the quarter
Find the month in the quarter
Find the day in the quarter

// Determine the month index within the quarter (91 days per quarter)
// and the day of that month (months of 31, 30, and 30 days respectively)
let monthIndex = 0;
let dayNumber = (diffDays % 91) + 1;
if (dayNumber > 31 && dayNumber <= 61) {
  monthIndex = 1;
  dayNumber -= 31;
} else if (dayNumber > 61) {
  monthIndex = 2;
  dayNumber -= 61;
}

const zeroBasedQuarter = Math.floor(diffDays / 91);
const monthName = MONTHS[zeroBasedQuarter * 3 + monthIndex];

const dayName = WEEKDAYS[diffDays % 7];

...and that's pretty much it!

You can find the results on a website I made to show the results and let you check when your birthday is on those calendars.

There's also a decimal clock if you want to check that out too.

Fiscal years and how JavaScript is wrong about months

Michel Billard — Wed, 09 Feb 2022 19:35:35 +0000

Developers love working with dates. One day, someone asked themselves, what if the year didn’t start in January, but could start in any month of the year. Welcome to the fascinating world of fiscality.

One of the neat things about fiscal months is that you can’t know in which fiscal year a date is in until you know what the fiscal month is. A date in August 2022 can be in fiscal year 2021 if the fiscal month is September or later and in 2022 otherwise. Also very fun is the fact that some libraries expect months to be represented by the numbers from 0 to 11, while others use 1 to 12. I don’t know about you but, if I see month 3, I assume March, not April. Oh, and JavaScript and Ruby don’t agree.

# ruby
Date.new(2022, 2, 3) # => February 3rd, 2022

// JavaScript
new Date(2022, 2, 3) // => March 3rd, 2022

That means you have to be very careful when passing month indexes from Ruby to JavaScript and vice versa.

Displaying fiscal years

Our customers have long been able to specify what their fiscal month was, but we recently launched a new setting to let the customers customize how to display the fiscal years and quarters in their accounts.

There doesn’t seem to be any standards for displaying fiscal quarters so we provide a few options: the abbreviated fiscal year (ex: FY22) or the full fiscal year (ex: 2022 or 2021/22 when the fiscal month is anything other than January) as well as the option to put the quarter at the front or at the back.

So we end up with something like this:

# The fiscal year is the year it ends so the fiscal year for October 2019
# when the fiscal month of March (3) is the next year (2020)

# Special case for the default fiscal month of January (1) since
# it doesn't span 2 years. The current year is always the fiscal year.
if fiscal_month == 1
  return long_fiscal_year_format ? year.to_s : "FY#{year % 100}"
end

before_fiscal_month = month < fiscal_month
if before_fiscal_month
  # Render the year the fiscal year ends (the current year)
  # ex: 2018/2019 or FY19 if we're in 2019 and the fiscal year ends in 2019
  long_fiscal_year_format ? "#{year - 1}/#{year % 100}" : "FY#{year % 100}"
else
  # Render the year the fiscal year ends (the next year)
  # ex: 2019/2020 or FY20 if we're in 2019 and the fiscal year ends in 2020
  long_fiscal_year_format ? "#{year}/#{(year + 1) % 100}" : "FY#{(year + 1) % 100}"
end

Add a few tests and you’ve got yourself a nice simple method for displaying fiscal years.

Making sense of the January = 0 confusion

We had a really hard time knowing when we were using a zero-based index or a one-based index so we made a few changes to make the code much clearer:

Always use the one-based months in Ruby
Always use the one-based months in JavaScript
When we need to use a zero-based month in JavaScript (to create a date for example), first assign it to a variable that ends with index (ex: fiscalMonthIndex), then call the function with that new variable.
Be generous with comments

For example, when trying to figure out the fiscal quarter, we could do something like this:

// The fiscalMonth goes from 1 - 12, but date.month() goes from 0 - 11
const fiscalMonthIndex = this.options.fiscalMonth - 1;
return (date.month() - fiscalMonthIndex) % 3 === 0;

Now there’s very little confusion when using month numbers.

Building our new Gantt chart: Lessons learned and insights

Michel Billard — Wed, 02 Sep 2020 15:17:10 +0000

Our old Gantt chart served us well for the past six years. It was doing what it was designed to do, but some of the things we wanted to add were either impossible or incredibly difficult to accomplish. For example, giving customers more control over their data by not forcing features and other records to stay contained within the dates of their parents. Or allowing customers to order the records the way they wanted, to choose which records appear and which ones don’t, and many more. Internally, we also wanted to support more data types so that we could reuse the same Gantt chart for multiple views. So we decided it was finally time to completely overhaul it. Here are some of the lessons we learned as we built this great tool.

All code samples are greatly simplified to keep the article readable.

Be shallow about what you put in your Redux store

One of the things we wished we learned earlier was to keep our Redux store objects as shallow as possible. Early on in the project, an object would look almost the same in the backend as in the Redux store. At first, it seemed fine but after struggling with one too many (not to be confused with one-to-many) bugs, we decided to move some of the object properties out of the objects themselves and into their own key-value pair in the store.

Before getting into the examples, let’s take a high-level look at the data structure. The Gantt chart has records with attributes and children that are themselves records with attributes and children, etc.

records: {
  recordId: {
    ...attributes,
    children: {
      childId: { ...attributes, children: [...] },
      …
    },
  },
  …
}

Let’s look at the feature that allows you to hide specific records from the Gantt chart. Our initial naive implementation was to add an isVisible attribute to the records:

class Record {
  constructor(isVisible = true) {
    this.isVisible = isVisible;
  }
}

This looks fine at first glance, but when we wanted to update a record’s visibility, we had to dig into the records tree:

const setIsVisible = (record, isVisible) => {
  state = state.setIn([records, parent.id, ‘children’, record.id, ‘isVisible’], isVisible);
};

And that’s for records nested one level deep. If they’re nested deeper, then we had to figure out the whole path to the record with things like:

record.parents.map(parent => parent.id).interpose(‘children’)

It didn’t make for the most readable code. We also had to maintain the value even when the parents and/or grandparents were updated, manipulated, etc.

We eventually found a much better way to handle this. We decided to keep a separate list of hidden records and query that list whenever we wanted to know if a record was visible or not:

let state = Immutable.fromJS({
  hiddenRecords: Immutable.Set(),
});

const setIsVisible = (record, isVisible) => {
  state = state.update(‘hiddenRecords’, set => isVisible ? set.delete(record.id) : set.add(record.id);
};

const isVisible = (record) => {
  return !state.get(‘hiddenRecords’).has(record.id);
};

Once we stumbled onto that pattern, we applied it to a number of other properties with great success. We added lists for expanded records, active records, selected records, and more.

It took some getting used to as we adjusted our mental model from working with an object-oriented system to a hybrid that is more functional.

SVG works great to draw a grid

If you look closely at our Gantt chart, you’ll see vertical lines separating the weeks, darker areas to show the weekends, and a red line to show where today is.

We used to populate the DOM with hundreds of DIVs with various borders to achieve the result we wanted. As an experiment, we tried constructing an SVG image dynamically and it turned out great: it was easy to implement, the code is clean, and the output is small compared to our previous DIV solution.

// All the shapes that make the final SVG image
const shapes = [];

// week dividers
for(let week = firstWeek, x = 0; week <= lastWeek; week++, x += pixelsPerWeek) {
  shapes.push(
    `<line id="week-${week}" x1="${x}" x2="${x}" y1="0" y2="100" stroke="rgb(204,204,204)" stroke-width="0.5" />`
  );
}

// today
shapes.push(
  `<rect id="today" x="${pixelsToToday}" y="0" width="2" height="100" fill="rgba(255,0,0,0.3)" />`
);

// ...and finally build the CSS style
return {
  background: `url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="${timelineWidth}" height="100">${shapes.join(‘’)}</svg>') repeat-y`,
};

Migrating from the original Gantt chart to the new one

Our new Gantt chart behaves differently in a number of important ways and has a different data structure than the original one, so how do we get new users to use it? We didn’t want to tell them to re-enter the same data in the new one because most of them wouldn’t have done it. We also didn’t want to keep the original one and maintain both at the same time. The only solution was to find a way to “migrate” from the original one to the new one.

To accomplish this, we created a migration service that is run automatically when someone tries to access their original Gantt chart, converts it into the new one, and then redirects to it. We looked at every single configuration attribute in both implementations, found how they mapped between each other, and implemented the logic. We also made sure to preserve the original configuration in case we did something wrong. (Nothing major happened.) The migration service was inspired by the Rails database migration. Here’s what it looks like:

class LegacyGanttChartMigration
  def upgrade
    preserve_legacy_configuration
    convert_date_attributes
    convert_expanded_records
    # … a few more convert calls
    hide_features_without_dates
  end

  def downgrade
    # revert the configuration preserved above
  end
end

# and to migrate, all we had to do was call this
gantt_chart = LegacyGanttChartMigration.new(gantt_chart).upgrade

The migration was easy to test, easy to read, and worked like a charm.

Why we don’t use React Virtualized

When you read the description of React Virtualized, it looks like a perfect match for our Gantt chart. They even have a demo for a MultiGrid that behaves very closely to what we were looking for: locked (or frozen) rows at the top, locked columns on the left, and a main grid that can scroll in both directions and stay aligned with the locked rows and columns. That’s why we initially implemented our new Gantt chart with it. Unfortunately, we had a lot of difficulties trying to keep all the parts working nicely together. We had issues with scroll bars in the panels that messed up the alignment, and no matter what we tried, we couldn’t figure out how to work around those issues. We even tried only using ScrollSync but there was always a tiny delay that made moving around the Gantt chart feel bad.

So in the end, we completely dropped the library and implemented what we needed ourselves. The Gantt chart is split into three main panels. When the user scrolls, all we have to do is synchronize the scroll position to the relevant panels. For performance-intensive features such as drag-and-drop, we implemented our own windowing to only render what’s visible on the screen to avoid costly computation for objects that aren’t visible anyway.

This isn’t the end

We’re continuously adding features and fixing bugs on our Gantt chart. As we’ve discovered new patterns and ways to do things, we’ve built a decent backlog of things we’d like to improve. Our customers also provide us with invaluable feedback that we always take into account when deciding what to do next. If there’s something missing from our Gantt chart, let us know. If you’d like to help us build it, we’re always looking for new talent.

Custom React hook to track the mounted status of a component

Michel Billard — Thu, 20 Aug 2020 15:47:03 +0000

Have you ever gotten this error:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

As the message implies, you're probably setting state asynchronously in a useEffect hook that you aren't cleaning up properly.

If for some reason you can't cleanup or clear the timeouts properly, you can use the following hook to verify just before setting state if the component is still mounted.

// useIsComponentMountedRef.js
import { useEffect, useRef } from 'react';

const useIsComponentMountedRef = () => {
  const isMounted = useRef(true);

  useEffect(() => {
    return () => {
      isMounted.current = false;
    };
  }, []); // Using an empty dependency array ensures this only runs on unmount

  return isMounted;
};

export default useIsComponentMountedRef;

...and to use it:

import useIsComponentMountedRef from './useIsComponentMountedRef';

const MyComponent = () => {
  const isMountedRef = useIsComponentMountedRef();

  // ex: isMountedRef.current && setState(...)
};