Move default messages into Globalize

[alunny]

As discussed in https://github.com/rxaviers/react-globalize-compiler/pull/5, the fact that react-globalize monkeypatches Globalize to support default messages (ie. using the string in the default language as the key for the message) complicates the code for react-globalize-complier and globalize-compiler. Large projects that use both react-globalize elements and calls to Globalize.messageFormatter/formatMessage can run into complications - some code might hit a Globalize that has been monkeypatched, while other code might hit an unpatched Globalize object.

If the default messages code were moved into Globalize itself, this would be much simpler.

[rxaviers]

:+1: I like the idea of moving that code in here. Basically, the patched API looks like this Globalize.formatMessage(pathOrMessageItself) and has a logic to either treat the first argument as a path or as the message itself (default message). It's an API that works for react-globalize. We could elaborate something more generic porting it over here, one idea is to require argument to explicitly tell what it's about, for example:

Globalize.formatMessage({
  path: <path>
});

// or
Globalize.formatMessage({
  message: <message>
})

@jquery/globalize any input anyone?

[rxaviers]

The lack of input at least shows we have no objections... :smile:

I would like to stress the API first. For the record: (a) should we make it backwards compatible (i.e., the Object argument above is incompatible with the current String one)? (b) consider supporting https://github.com/rxaviers/react-globalize-compiler/issues/6

[rxaviers]

cc @Setogit... By looking at your examples at strong-globalize I believe you do something similar in your end. I thought you could be interested in this issue as well. We are aiming to bring default message functionality over to Globalize.

[necolas]

Andrew pointed me here after I uncovered the same issue. Part of the globalize compiler tool chain can't extract messages from FormatMessage elements that are moved as part of babel/react code optimizations. I was looking into dropping our dependency on react-globalize (which I assumed would be faster than finding/fixing the compiler issue) so that we can use these optimizers, but then found that the way we use globalize is dependent on react-globalize's monkey-patching :).

[rxaviers]

Hi @necolas, thanks for your input.

I'm open to bring this feature into Globalize. I believe it's a good move and no one went against it so far. Although, we lack resources in order to implement it. Would anyone from your team be interested in contributing this feature?

About the compiler issue, although addressing this in Globalize fixes it for you, I still think it would be good and helpful to know more about the details of the problem you faced. Could you file an issue in https://github.com/jquery-support/globalize-compiler or https://github.com/rxaviers/react-globalize-compiler/ (the one that seems most appropriate) please? Thanks