feat(admin-ui): Add rtl compatibility to some admin-ui components

[HoseinGhanbari]

ModalDialogComponent is now supporting dynamic direction (ltr/rtl) based on the language & locale provided by dataService.

[HoseinGhanbari]

DropdownMenuComponent is now supporting dynamic direction (ltr/rtl) based on the language & locale provided by dataService.

[HoseinGhanbari]

ThemeSwitcherComponent is now compatible with rtl layouts.

[HoseinGhanbari]

NotificationComponent is now supporting dynamic direction (ltr/rtl) based on the language & locale provided by dataService.

[HoseinGhanbari]

NotificationService's unit tests using ng test can now be completed successfully without any failures.

[michaelbromley]

Hi,
Thanks for this contribution! I have an idea about how we can simplify this: the current ui language is always stored in local storage and thus it should be possible to be retrieved from the affected components using:

export class NotificationComponent implements OnInit {
  direction: 'ltr' | 'rtl';

  constructor(private localStorageService: LocalStorageService, private i18nService: I18nService) {
    this.direction = this.i18nService.isRTL(this.localStorageService.get('uiLanguageCode');
  }

}

Can you try to refactor like this and see if that works? That would cut down on the amount of code we need to add quite significantly.

[HoseinGhanbari]

Yeah, I'll give it a shot. but I think there may be cases that setting the direction inside constructor wouldn't take effect when user try change the locale/language at runtime/asynchronously. Actually we have to update the direction based on the user interactions and on an observable basis. I will keep you updated. But let me know if you are ok with setting direction inside constructor.

Also note that, as an alternate solution, we can create some sort of BehaviorSubject on a shared service that every component which requires awareness of current ltr / rtl status can subscribe and do the rest inside their ts file.

[michaelbromley]

My thinking was that since the language can only be set in 1 place (the language dialog) then it might be ok to assume a static value for a given component. But is this causes edge-cases then my 2nd choice would indeed be to encapsulate the observable logic in a shared service.

[HoseinGhanbari]

Thank you for your reply. I will soon update the strategy on accessing direction, refactor the whole changes and keep you updated. 🚀

[HoseinGhanbari]

• new LocalizationService with its minimal unit test has been added.
• both uiLanguageAndLocale$ & direction$ has been moved to LocalizationService.
• new shared types called LocalizationLanguageCodeType & LocalizationDirectionType has been extracted.
• all usages of uiLanguageAndLocale$ & direction$ is now referencing LocalizationService.
• small scss & autoprefixer warning related to theme-switcher.component.scss has been resolved.
• access to ltr/rtl status is now as easy as the following.

import { LocalizationDirectionType, LocalizationService } from '../../providers/localization/localization.service';

export class NotificationComponent implements OnInit {
    direction$: LocalizationDirectionType;

    constructor(private localizationService: LocalizationService) { }

    ngOnInit(): void {
        this.direction$ = this.localizationService.direction$;
    }
}

[michaelbromley]

Beautiful refactor, thank you!

[HoseinGhanbari]

Its my pleasure! 👌