Extending helpers like FormatDate has braking changes between v6.2.2 and v6.3.0+ about ember-intl HOT 5 CLOSED

The only bad thing was, that the function was internal changed/removed, which i haven't expected in an minor update.

Definitely. It's something that I, as an end-developer of some addon, would hate to experience as well.

Unfortunately, to remove ember-intl's tech debts, I think v6.x will have to make some changes that may be non-breaking for 80% of the consuming apps, and ask the other 20% to make adjustments on their end. Of course, we'll document how projects may migrate their code in release notes and issues like this.

At the moment, adding features isn't on the table, but I'll keep your suggestion in mind. I'd like to simplify code first so that we can introduce features in a good, sustainable way.

from ember-intl.

I'll close this issue, as it documented a couple of ways to migrate code.

from ember-intl.

Hi, @mkszepp. The issue that you described seems similar to #1813, where an end-developer overwrote a helper that ember-intl provides, to change the helper's default behavior.

I think this is a brittle approach. Whether your helper works depends on ember-intl's implementation details (e.g. the compute() method used to call another method called format()) and can prevent ember-intl from changing the implementation for the better.

In your case, I think it'd be better to explicitly set the format option in your template(s), as documented in https://ember-intl.github.io/ember-intl/versions/v6.1.0/docs/helpers/format-date#custom-format. Would this be another possibility? (That is, if there aren't many places where you called {{format-date}}, I'd go ahead with adding the format option.)

from ember-intl.

An alternative is to create a helper that extends the Helper class from @ember/component/helper and injects the intl service.

import Helper from '@ember/component/helper';
import { inject as service } from '@ember/service';
import type { IntlService } from 'ember-intl';

export default class MyFormatDateHelper extends Helper {
  @service declare intl: IntlService;

  constructor() {
    // eslint-disable-next-line prefer-rest-params
    super(...arguments);

    // @ts-expect-error: Property 'onLocaleChanged' is private and only accessible within class 'IntlService'.
    this.intl.onLocaleChanged(this.recompute, this);
  }

  compute([date], options): string {
    if (!options.format) {
      return this.intl.formatDate(date, {
        ...options,
        format: 'default',
      });
    }

    return this.intl.formatDate(date, options);
  }
}

I think this is still not an ideal solution, as implementation details are leaked in the constructor and the type for options in compute().

from ember-intl.

Hi @ijlee2 ,

thank you for your response.
I don't like to work with code functions/properties that are intended only for internal/private uses, because there are not documented and could changed any time without any notification.

I think, my actual helper extending is the best way, because i don't like to set the format in every implementation manually, because the date format should equal in all cases.

The only bad thing was, that the function was internal changed/removed, which i havn't expected in an minor update.

A possible enhancement for the addon could be, that the service allows to pass default formats... what do you think about that? Is something like that possible?

from ember-intl.