2019 03 04 Model and Presenters

Making Enchilada

After we introduced our first "mini" interactor, will it be time to decouple the next element.
The next part in your Enchilada receipt is...

The view

This time is it the view part. The Settings.html.tpl contains currently:

    <li
            class="mdc-list-item"
            role="option"
            id="google"
            tabIndex="0"
            {...(this.props.themesManager.activeTheme === 'google' ? {'aria-selected':'true'} : {})}
    >

The template "knows" the Themes Manager. That we want now to change.

Goal of the view split:
I want make the view "stupid" and the view should not "know" which architecture is behind.

Target code will be like:

    <li
            class="mdc-list-item"
            role="option"
            id="google"
            tabIndex="0"
            {...(this.view.activeTheme === 'google' ? {'aria-selected':'true'} : {})}
    >

Yes it is a very tiny step from this.props.themesManager.activeTheme to this.view.activeTheme. But the effect will move hills.

The view model(this.view) will be an Open Object. So its just a collection of properties, which the template can use.

But wait! "Who" will fill the view with the data?
Here comes the ...

Presenter

The presenter aggregates[¹] all values which the view will need.

Maintenance notice: Add only values, which real will be need. All properties in view, which are obsolete must be removed.

So far I interpret the recipe correctly, is the view and the presenter bound to the case.

Should the presenter create the view model. Here I'm not sure. But if we say, that the view and presenter are bound to case(better view case), than I don't see yet, why it should been created outside.
So let's experiment and let create the view model by presenter.

Translations

What about translations? Are labels and other language stuff kind of view data?
The next experiment: Let's say yes! That lead into the effect, that the Language Translator will not anymore configured by the component itself. Now it will be injected into the presenter. (Is that to crazy?;)

Edit:
While implementation I can confirm, that I was able to remove some workarounds in the language files.
The language selection lead into the value de_DE. But my selection identifier is german. So the language file lead into a double translation:

  selection:
    lang:
      title: Select Language
      german: German
      de_DE: German
      english: English
      en_US: English

Now took the presenter that duplication into:

    view.labels = {
      languageSelectionTitle: this.translator.translate('settingBox.selection.lang.title'),
      german: this.translator.translate('settingBox.selection.lang.german'),
      english: this.translator.translate('settingBox.selection.lang.english'),
      de_DE: this.translator.translate('settingBox.selection.lang.german'),
      en_US: this.translator.translate('settingBox.selection.lang.english')
    };

and the translation is cleared now:

  selection:
    lang:
      title: Select Language
      german: German
      english: English

Finally

We decoupling now language translations and other view values from the component. What we lost now, is the actualization, after the language or color change.

That will be a future blog page about spread global affecting data.

[¹]: Thanks to the colleges of Valiton for that word in this case.