Issues consuming Globalize as a library

[jquense]

Hi there again :wave:

I'm back with some residual concerns from the long closed: https://github.com/globalizejs/globalize/issues/441. I've attempted more than a few times to support Globalize as a i18n option in react-widgets with some hardship. The strategy in RW is to allow pluggable localizers, so I don't have to tie folks to a particular i18n choice. However i've found that helping folks use [email protected] the right way is really really hard.

localizers look a bit like this:

export default function(Globalize) {
  setLocalizer({
    date: Globalize.dateFormatter({ date: 'short' }),
    time: Globalize.dateFormatter({ time: 'medium' }),
  })
} 

The consumer of react-widgets picks the localizer they want passes Globalize to it and react -widgets sets up and uses those formatters for it's internal needs. The part about passing Globalize to it is important, because I don't want to require users to use globalize or ship extra code to them. Given how npm and peer deps work, the cleanest way to do that is to not have a dependency on globalize directly.

This leads the the following issues:

1. There isn't any good way for me to provide compiled formatters for the formats I use internally to a user without compiling them to every single locale.
2. Users can't easily compile them, via the webpack plugin, because my code is in node_modules and doesn't import Globalize (the plugin only extracts from files requiring globalize)

This places me in a spot where i need to provide extremely bespoke instructions on how to manually install and compile these files. at which point its hard to recommend Globalize anymore.

I'd really love to figure out how to make this experience better, Globalize is a great project and it stinks when folks give up on it when it's hard to use. The WebpackGlobalizePlugin is a good start, but as soon as it doesn't cover one edge, you are forced to bail out and write everything yourself, and there is very little documentation covering what is needed to work. The compiler is also cool but feels neglected at this point.

I'd be happy to help where I can, i've already built out a babel plugin to extract formatters which is more like how react-intl works.

[kborchers]

Hi @jquense. Hopefully I'm not jumping in out of turn and @rxaviers can tell me to be quiet if he likes 😉 but I just happened to see this email pop up and wanted to comment.

Globalize really needs help and you sound like someone who has a good understanding of the project and a desire to make it better which is the perfect combination. You mention a number of places where things are "too hard" or in need of more documentation and I know this project would love help in those areas. I think this issue is great for context as to how you've come across these problems but I think what may be more helpful are smaller, more specific issues for each of those trouble spots you see where a user's understanding falls apart and could be helped by better documentation or even improvements to the API. With more consumable issues like that, it will be easier for folks like @rxaviers and @alunny and @jzaefferer to review, comment and discuss them and give direction on how you can further contribute.

I realize this doesn't immediately solve your issue but I think a more solid project with better documentation serves everyone better and provides for more users which some then become contributors and the project just keeps getting better. Happy to help with further guidance where I can and I'll step back and let the real project members jump in. Thanks!

[rxaviers]

Thank you @jquense for bringing these points up to us and @kborchers for your reply.

@jquense, as Kris said your help to the project is very welcome...

because I don't want to require users to use globalize or ship extra code to them

It seems like a good approach to me.

There isn't any good way for me to provide compiled formatters for the formats I use internally to a user without compiling them to every single locale.

Right. You could use globalize-compiler to generate the pre-compiled formatters, but I agree that isn't ideal. Note, globalize-compiler will parse fine your Globalize calls (static methods), but wouldn't for any instance calls (not supported yet*). (*: no plan to do so, but patches are welcome).

By the way, src/localizers/globalize.js (even on 4.0.0-beta-5) seems to be using Globalize 0.x, not 1.x. Do you have any code publicly available using Globalize 1.x so that I can see please?

2. Users can't easily compile them, via the webpack plugin, because my code is in node_modules and doesn't import Globalize (the plugin only extracts from files requiring globalize)

Right, although I have an idea, see below.

For context, the webpack plugin only extracts from files requiring globalize for efficiency and safety. In theory, it could try extracting from all files, but the chances of extracting zero formatters from a file that doesn't require globalize is high. :) Anyway:

What if you moved your localizers away from react-widget, so you can define/list their dependencies in its own package.json and put a require there. There could be a react-widget-globalize-localizer package that is exactly what you have in mind with the exception that it require('globalize') and have it listed as a dep in its package.json. The developer would import 'react-widget-globalize-localizer' and pass it to react-widget as an argument. The only change he would probably have to make in his webpack config is to whitelist react-widget-globalize-localizer from his node_modules excludes.

Does that make sense? What do you think?

Otherwise, what changes would you like to see in order to enable your use case?

[rxaviers]

@jzaefferer could have ideas here as well since he has experience with both jQueryUI and Globalize. jQueryUI might have the same sort of challenge in its to-be-released datepicker.

[jquense]

thanks for the reply :). Sorry the react-widgets code wasn't up to date here is the latest version

I've thought about (and have at points) split out the localizers into separate packages. the tough bit there is maintainability for me, and ease of use of users. It's nice to not have to download and install extra packages to use the library. That said, tooling can make that easier and it's a good idea i should revisit. I'd be very interested how jQuery UI's datepicker is going to handle this sort of thing.

I think it's just hard to understand what the steps are for setting up an app, apart from env idiosycracies like webpack hating the UMD wrapper ya'll use :P I can't think of some specific issues that i'd like to see changed (or don't know how to change them) but I can, PR stuff to the individual projects as I run into them. Maybe some official direction for what libraries would need to do to not burden users with a lot of lib specific setup, while also making sure we structure code in a way that works neatly with the globalize tooling