Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(ivy): i18n - factor out localization utils for re-use #32488

Closed

Commits on Sep 12, 2019

  1. feat(ivy): i18n - reorganize entry-points for better reuse

    This is a refactoring that moves the source code around to provide a better
    platform for adding the compile-time inlining.
    
    1. Move the global side-effect import from the primary entry-point to a
       secondary entry-point @angular/localize/init.
    
       This has two benefits: first it allows the top level entry-point to
       contain tree-shakable shareable code; second it gives the side-effect
       import more of an "action" oriented name, which indicates that importing
       it does something tangible
    
    2. Move all the source code into the top src folder, and import the localize
       related functions into the localize/init/index.ts entry-point.
    
       This allows the different parts of the package to share code without
       a proliferation of secondary entry-points (i.e. localize/utils).
    
    3. Avoid publicly exporting any utilities at this time - the only public
       API at this point are the global `$localize` function and the two runtime
       helpers `loadTranslations()` and `clearTranslations()`.
       This does not mean that we will not expose additional helpers for 3rd
       party tooling in the future, but it avoid us preemptively exposing
       something that we might want to change in the near future.
    
    Notes:
    
    It is not possible to have the `$localize` code in the same Bazel package
    as the rest of the code. If we did this, then the bundled `@angular/localize/init`
    entry-point code contains all of the helper code, even though most of it is not used.
    
    Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn`
    and `TranslateFn`) defined in the `@angular/localize/init` entry-point because
    these types are needed for the runtime code, which is inside the primary
    entry-point. Importing them from `@angular/localize/init` would run the
    side-effect.
    
    The solution is to have a Bazel sub-package at `//packages/localize/src/localize`
    which contains these types and the `$localize` function implementation.
    The primary `//packages/localize` entry-point imports the types without
    any side-effect.
    The secondary `//packages/localize/init` entry-point imports the `$localize`
    function and attaches it to the global scope as a side-effect, without
    bringing with it all the other utility functions.
    
    BREAKING CHANGES:
    
    The entry-points have changed:
    
    * To attach the `$localize` function to the global scope import from
    `@angular/localize/init`. Previously it was `@angular/localize`.
    
    * To access the `loadTranslations()` and `clearTranslations()` functions,
    import from `@angular/localize`. Previously it was `@angular/localize/run_time`.
    petebacondarwin committed Sep 12, 2019
    Copy the full SHA
    187bb1b View commit details
    Browse the repository at this point in the history