What is this `tuiMode` all about? #1531

loxy · 2022-03-19T21:50:47Z

loxy
Mar 19, 2022

Hi!

I tried to understand more of the controller principle, like described here and here.

And I like it. But I do not really understand how this concepts is transported to tuiMode.

Seems that this component is some kind of glue. But for me TuiModeDirective is also a little bit like a ghost. It only includes a Subject with TuiBrightness output which is now somehow connected to DI.
Some components introduce themselves as instance of TuiModeDirective (via useExisting: forwardRef(() => <Self>), for example TuiDocMainComponent or TuiDocDemoComponent. Lets call them producers. Some are tweakers like TuiDocNavigationComponent, which pipe the observable. And some are consumers, like TuiCheckboxBlockComponent.

Your solution only excepts two different kind of modes (ok, there is also this null). So, it mainly looks like a night mode. And also very complicated for implementing a light/dark design.

The same could be archived with simply adding some selector to your elements with some mechanism for automation if you need. Something like:

:root, .on-light, [data-theme] {
  // your color definition
}

.on-dark, [data-theme=onDark] {
  // your re-defined color definitions
}

.on-purple, [data-theme=onPurple] {
 // another style
}

You can still apply your theme injection method like via TuiThemeNightComponent and overriding at run time (to save some bytes, I guess?)

I'm lost. What is this tuiMode all about? So, what is the benefit? Can you explain more? The docs a very thin.

Best regards,
Kersten

P.S.
One thing is outdated. At least seems so: TuiCustomizationComponent. It only appears in ExampleTuiPrimitiveTextfieldModule. And there it is commented out with hint to removal.

Answered by waterplea

Mar 20, 2022

Well, there are few point to mention:

Not everything can be just a CSS variable override, sometimes components need to know that they are in the night mode or not, for example to enable shadow or add border. This might be solved by host-context, but read further
Mode directive is used to create localised dark themes. For example if you have a promotional banner with dark photo and some email input and subscribe button on top. Overall site can be light, but a particular section has to be dark.
Those sections can have any level of nesting and with host-context once there is one dark section all children will be dark, no way to override it
Sometimes you want them to propagate across DI tree…

View full answer

waterplea · 2022-03-20T11:20:40Z

waterplea
Mar 20, 2022
Maintainer

Well, there are few point to mention:

Not everything can be just a CSS variable override, sometimes components need to know that they are in the night mode or not, for example to enable shadow or add border. This might be solved by host-context, but read further
Mode directive is used to create localised dark themes. For example if you have a promotional banner with dark photo and some email input and subscribe button on top. Overall site can be light, but a particular section has to be dark.
Those sections can have any level of nesting and with host-context once there is one dark section all children will be dark, no way to override it
Sometimes you want them to propagate across DI tree and not DOM tree. Like hints, they are in hints portal and therefore cannot rely on CSS, but if hint directive is inside dark mode then hint bubble would be white as per dark theme

2 replies

loxy Mar 20, 2022
Author

Thank you for your answer! But I'm still not convinced:

Exactly, :host-context can solve many problems. Something like:

:host-context( .on-dark ) {
    // redefine colors
    // remove borders
    // add shadows
}

Of course, you have to know the context before. But in Taiga UI they are fixed as well. No way to use a different "theme" with tuiMode.

Yes. Totally agree. But this works as well:

<body class="on-light">
  <p>Hello, I'm whity</p>
  <div class="on-dark">
    <p>And I'm dark</p>
    <div class="on-light">
      <p>I'm white again</p>
    </div>
  </div>
</body>

Do not fully understand. See example of 2). When you have another nested component which again re-assigns you basically overwrite it.

Ok, this is an example where you cannot just add a selector to some parent component. First, I would argue that you always apply some global theme, right. So, you end up with something like <tui-root data-mode="onDark"> or a selector on body. So all your portal related stuff works unless you want to overwrite for specific section. But it should be also easy to use a class on content template, something like:

<button
    tuiLink
    mode="pseudo"
    tuiDropdownAlign="right"
    tuiDropdownDirection="top"
    [tuiDropdownContent]="dropdownContent"
    [tuiDropdown]="open"
    (mouseenter)="onMouseEnter()"
    (mouseleave)="onMouseLeave()"
>
    Alex
</button>
will answer you with joy!
 
<ng-template #dropdownContent>
    <div class="dropdown on-dark">
        <tui-avatar
            size="l"
            [rounded]="true"
            [avatarUrl]="avatarUrl"
        ></tui-avatar>
        <div class="text">
            <div class="label">Taiga UI developer</div>
            <div class="name">Alex Inkin</div>
            <div class="account">a.inkin</div>
        </div>
    </div>
</ng-template>

I get the point that you want to have control of all of this via some logic. And different image loading is maybe the best use case.

But for other library users it is maybe not that useful. As I said, we cannot re-use the night-theme component as we cannot change the underlying variables, we have to introduce our own theme component. This is easy. True. But not that easy if you use in combination with addon docs. We need to create our own main docs just to replace the theme switcher (if we want control over light/dark mode).
And we cannot use different / custom modes. There is only onDark and onLight...

I just want to city @MarsiBarsi from a comment after his second blog article:

Yes, we can compare the hierarchy with CSS custom properties and it's a good idea to use CSS custom properties if we need to customize CSS only. And such directives replace Angular @inputs: if you can replace your Angular @input with CSS property, it is better to do it anyway.

Maybe it should only be better documented. It is not that easy to follow this approach...

Best regards,
Kersten

waterplea Mar 20, 2022
Maintainer

Your example from 2 would break because host-context(.on-dark) would still match on the nested on-light section. This approach doesn't work with multiple nested modes. I believe this directive was created when we still supported IE11 so we could only polyfill global CSS variables.

I'm not sure what's your concern is. Addon Doc is pretty specific thing so it has this night mode switch built-in with no customisation. But if you are making your own thing it's easy to customize themes with our abstract theme switcher class. As for mode — yes, there's only 3 modes because this is how much modes are built into default components. You can create your own appearances that rely on different modes and for can extend our mode directive and add more modes.

I agree on documentation issues, Taiga is huge and there's always no time to properly document all the nuances 🙁

loxy · 2022-03-25T07:50:38Z

loxy
Mar 25, 2022
Author

You are right. Example 2 is not working together with host-context because specificity would then take over over proximity. And in that case the source order (the last host-context you specify) would be the relevant part. Damn.

And I have no concerns. Just want to understand how it works and how it can be useful for me. For the documentation we can create our own frame. No problem.

But I have another question. Sorry when I'm annoying...

In most of your components you use the MODE_PROVIDER token to "attach" the mode together with EventManagerPlugins, something like:

host: {
    '($.data-mode.attr)': 'mode$',
},

But in some components you use another approach (for example TuiInputRangeComponent):

@HostBinding('attr.data-mode')
get hostMode(): TuiBrightness | null {
    return this.modeDirective && this.modeDirective.mode;
}

Why? It seems it has the same effect at the end (but first one is dynamic)...

3 replies

waterplea Mar 25, 2022
Maintainer

Yes, the second one is dated and should be refactored to the new one which is '($.data-mode.attr)': 'mode$',

loxy Mar 25, 2022
Author

Ok, is it already planned? Otherwise I can do that. I think there are 7 legacy components

waterplea Mar 25, 2022
Maintainer

You can go ahead and make a PR. Don't forget to add MODE_PROVIDER.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Taiga UI family

What is this `tuiMode` all about? #1531

{{title}}

Replies: 2 comments 5 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Taiga UI family

What is this tuiMode all about? #1531

loxy Mar 19, 2022

Replies: 2 comments · 5 replies

waterplea Mar 20, 2022 Maintainer

loxy Mar 20, 2022 Author

waterplea Mar 20, 2022 Maintainer

loxy Mar 25, 2022 Author

waterplea Mar 25, 2022 Maintainer

loxy Mar 25, 2022 Author

waterplea Mar 25, 2022 Maintainer

What is this `tuiMode` all about? #1531

loxy
Mar 19, 2022

Replies: 2 comments 5 replies

waterplea
Mar 20, 2022
Maintainer

loxy Mar 20, 2022
Author

waterplea Mar 20, 2022
Maintainer

loxy
Mar 25, 2022
Author

waterplea Mar 25, 2022
Maintainer

loxy Mar 25, 2022
Author

waterplea Mar 25, 2022
Maintainer