The latest updates on your projects. Learn more about Vercel for Git ↗︎

size-limit report 📦

my personal opinion is that these helpers should not be part of Lingui (not even the helpers for date and number).

Could you elaborate why?

But I'm not the one to decide :)

Who should? This is the best and worse part of the opensource, someone need to take decision and show the direction of the development, but every one could put it's own 5 cents into discussion. It's very hard to take all decisions alone, considering the fact i'm even not an official maintainer

BTW, the PR looks good to me

hi! Let me expand on it (I thought you were somehow more involved on the project @timofei-iatsenko, sorry).

• the i18n.date and number are just proxies over Intl apis. There are many Intl apis and if we create proxy over X, question arises whether we should create a proxy over Y too. Where to stop? Well, for me the answer is to not start adding proxies in the first place. Or at least not add more of them.
• people don't understand that these apis are proxies and when they see an issue, they blame Lingui: Inconsistent numbers localisation in different runtimes (node and chrome) #1203 Android: Date formatting issue in React Native for Chinese locales #2123 react native expo i18n.date and i18n.number return some string but not formatted date #1706
• I believe it was discussed that class methods are hard / impossible to tree-shake. So even if the method is not used in a bundle, it'll be there

People should understand that these apis are no magic, just Intl apis. And so I'd suggest they use:

const getIntl = (locales) => new Intl.ListFormat(locales, myFavoriteFormat)
const memoized = memoizeOne(getIntl)

export function listWithMyFavoriteFormat(
  i18n: I18n,
  values: string[],
): string {
  const _locales = i18n.locales

  const formatter = memoized(_locales)

  return formatter.format(values)
}

similar PR was previously rejected for these reasons: #1708

Then maybe move date, number and this list into helper/util package, user can import them as needed.

@vonovak that's a fair enough. From other side, i found it really useful in our project. It's shorter, doing all needed essentials (memoization, current locace, etc)

The @dsonet proposition is also good, but could not imagine right now a good API for this one. Currently, it's implemented as i18n instance methods, so it always has access to the current locale and works for react / vaniala and any other solution.

If you create this as a separate helpers, you will have to pass i18n instance manually or pass locale and it wouldn't be much difference from just using intl apis directly.

For react that could be achived by the additional hook, which will tie everethying together, but that would only for react, for other platforms has to be re-done

Codecov Report

Attention: Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 76.80%. Comparing base (6bb8983) to head (b3f2283).
Report is 186 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2223      +/-   ##
==========================================
- Coverage   77.05%   76.80%   -0.25%     
==========================================
  Files          84       88       +4     
  Lines        2157     2492     +335     
  Branches      555      648      +93     
==========================================
+ Hits         1662     1914     +252     
- Misses        382      463      +81     
- Partials      113      115       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

From other side, i found it really useful in our project. It's shorter, doing all needed essentials (memoization, current locale, etc)

I have no doubt it's useful but from a library maintenance point of view I find it problematic.

If you create this as a separate helpers, you will have to pass i18n instance manually or pass locale and it wouldn't be much difference from just using intl apis directly.

is i18n.list(["a", "b", "c"], { type: "conjunction" }) really that much better than list(i18n, ["a", "b", "c"], { type: "conjunction" })? The first one requires code in the library that comes with the issues I listed above. The second lives in userland. And yes, there's not much difference from Intl apis directly, and that's a good thing! That makes it more transparent.

These helper functions are 5-10 lines and we could just list them somewhere for people to copy-paste them into their projects. Zero responsibility for Lingui - it's the responsibility of Intl.

Makes sense! We've already gone with a userland wrapper, since we wanted to take these into use as soon as possible.

The wrappers are convenient, but probably not worth library maintenance