Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In scope of modular implementation in Nepal support for secondary calendar was added. While previous solution allowed to replace one calendar with the other, new solution allows user to easily switch between Gregorian calendar and second calendar of choice.

Code Block
- `secondCalendarFormatting`: formatting options for second calendar (both picker and display), default: "DD-MM-YYYY"
- `secondCalendarFormattingLang`: formatting language for second calendar (when displayed as saved data, not in pickers), default: "en"


Current implementation will need refactoring if it were to use any other calendar than Nepali. It looks like this:

Code Block
export function formatDateFromISO(mm, intl, date) {
  const isSecondaryCalendar = JSON.parse(localStorage.getItem(STORAGE_KEY_SECONDARY_CALENDAR));
  if (isSecondaryCalendar) {
    const secondCalendarFormatting = mm.getConf("fe-core", "secondCalendarFormatting", DEFAULT_SETTINGS.SECOND_CALENDAR_FORMAT);
    const secondCalendarFormattingLang = mm.getConf("fe-core", "secondCalendarFormattingLang", DEFAULT_SETTINGS.SECOND_CALENDAR_LANG);
    return neFormateDateFromISO(date, [secondCalendarFormatting, secondCalendarFormattingLang]);
  }
  return adFormateDateFromISO(mm, intl, date);
}

So if isSecondaryCalendar option is enabled it will default to Nepali version. This could be reworked by other implementations in the future.

Currently we had to write separate DateFormatter for Nepal. New formatters would have to be written and added here to be accounted for by the code.

Additional thing worth mentioning:
isSecondaryCalendar is a variable representing current state of a date switcher - it tells openIMIS which calendar to show - gregorian or secondary (nepali in this case). We cannot come up with any other way than to write it down as a cookie and then read every time the button is pressed.

Other solutions seems to be to complicated to work, and other that was simple and obvious uses hooks. Hooks are used in react functional components and cannot be used in class components. And because this function is called across whole openIMIS, which is written mainly in class components this causes immediate failure of the frontend. If at some point openIMIS is reworked to rely on functional components only this could be reworked.

Product cycles (back-end)

...