[Feature Request][localize] Offer plain text formatting to reduce bundle size (on demand rich formatting?)

[LarsDenBakker]

Localize includes message-format by default. message-format is somewhat large: 21.4kb (https://bundlephobia.com/[email protected]) and along with axios and lit-element contribute mostly to lion's size.

I think message-format is a very useful library, but I don't think it's worth the cost for most use cases. I think mostly people just need the variable replacement such as 'hello {message}' and the message selection functionality.

I think that it would be better if the LocalizeManager offers plain and rich formatting. Plain formatting can only do variable replacement using a simple regexp, and rich formatting lazily loads message-format and uses that for formatting.

This way apps can stick to simple formatting for their initial load, and perhaps use rich formatting for more specialized components if they really need it.

What do you guys think?

[tlouisse]

Think it's a very good idea, was also thinking about something like that before.

What currently bothers me that if you only want to load one ui element (lion-input for instance), you are obliged to (synchronously) load MessageFormat first.
For the average 'replace key' error message that is not needed indeed. (we currently only need it for date formatting, which should be solvable in different ways).

[LarsDenBakker]

The date formatting will use plain Intl, right? So it won't get any of the date formatting fixes done by lion for certain browsers / locales?

[bashmish]

@LarsDenBakker yeah, that's not nice that we don't patch Intl MessageFormat too, we should.

[bashmish]

I can hardly imagine a page without dates, times and numbers, so even if we implement smth like you proposed the impact on performance will be quite low. We still need date, time and number formatter by default IMO.

The other thing is why is it 21.4KB? Maybe we can have a subset for these format out-of-the-box and implement it with our patched localize helpers for dates and numbers. And then the impact might be worth it.

Still a question to me how people switch from "plain" (or better "default") to "rich"?

[tlouisse]

The date formatting will use plain Intl, right? So it won't get any of the date formatting fixes done by lion for certain browsers / locales?

What I mean is date formatting in the messages (probably uses Intl under the hood, but not part of our simple 'plain' layer):
https://github.com/ing-bank/lion/blob/feat/richSelect/packages/validate/translations/en.js#L15

What I mean with solvable in other ways is formatting the date ourselves(via Intl indeed) before we pass it to localize

[tlouisse]

Still a question to me how people switch from "plain" (or better "default") to "rich"?

So for our core (Lion) components, we should not depend on "rich" then.
The more advanced syntax could be loaded on request by Application Developers (dynamically imported by LocalizeManager, triggered by flag (setter/getter) called by App Developer. Then whenever the setter is true (on LocalizeMixin) for instance, it delays translations until MessageFormat is there )

[LarsDenBakker]

The reason it's so large is because it includes a lot of data per locales to handle features like pluralizations. All locales are always loaded. For example: https://github.com/format-message/format-message/blob/master/packages/format-message-interpret/plurals.js#L379

Because we are formatting messages from javascript, there is hardly any added value from the special date and number formatting syntax. You can just do this:

export default {
  MY_MESSAGE: 'Your birthday is: {birthDate}'
}

render() {
  return html`
  ${this.msg('MY_MESSAGE', { birthDate: formatDate(birthDate, { weekday: 'long', year: 'numeric', month: 'long', day: '2-digit' }) })}
`;
}

That just keeps it clear and there is one way to do it, in my opinion.

There are different options for switching between plain and rich:

Separate methods

render() {
  return html`
    ${this.msg()}
    ${this.msgRich()}
  `;
}

Options:

render() {
  return html`
    ${this.msg('MY_MESSAGE', {}, { rich: true })}
  `;
}

[tlouisse]

render() {
  return html`
  ${this.msg('MY_MESSAGE', { birthDate: formatDate(birthDate, { weekday: 'long', year: 'numeric', month: 'long', day: '2-digit' }) })}
`;
}

That just keeps it clear and there is one way to do it, in my opinion.

That's kind of what I meant for dates indeed👍

WIth regard to proposed new msg apis: maybe we should always try to find a balance between DX(one easy way of doing things) and feature richness. Also, for the suggested apis above we already have msgLit(should we add msgRichLit then?) and all of the suggested apis would be breaking.

Alternative: the 'hard' api will be exclusive to us or feature developers requiring quick first paint. When we want to finetune for performance, we could opt out of loading MessageFormat? Like:

${this.msgPlain('MY_MESSAGE')}

or

LocalizeMixinInstance.preventMessageFormatImport = true;

[LarsDenBakker]

Yeah I guess you'd need to keep the current behavior to avoid breaking changes.

I do think it's best to make the rich formatting opt in, and let the plain formatting be the default. That's something to consider perhaps when introducing the next breaking changes.

[LarsDenBakker]

Unfortunately msg is synchronous, so it can't lazy load message-format as it is.

I wonder how many people use the formatting beyond just variables, and if we could just not get by making plain the default and add a rich option.

[LarsDenBakker]

@daKmoR @tlouisse is this something we can plan for the next breaking release?

[tlouisse]

@LarsDenBakker yeah, it would be a really nice improvement and it is planned for next breaking release of our extension layer (and then probably plain by default and rich on demand like you suggested).

Here I already made an implementation that seems to work: https://github.com/ing-bank/lion/blob/feat/improveValidateSystem/packages/localize/src/LocalizeManager.js#L24

[LarsDenBakker]

Awesome, that's great!

[tlouisse]

See: #356

[erikkroes]

Hi,

We are closing this issue because we're changing the way we handle feature requests. Your issue will get the "votes needed" label, and people can add 👍 reactions to vote and show interest. It will be reopened when this feature gets picked up.

This we way we clearly focus on bugs in our open issues. At the same time we can see what community interest there is for new features.

Thanks!