Pull to refresh
0
0

User

Send message
В общем, когда ребята из двух лагерей подружатся и общими усилиями заменят ангуляроские шаблоны+фильтры+директивы+контроллеры реактом на моей улице наступит праздник))
Ну, если не пользоваться * то вместо вот этого:

<todo-cmp *ngFor="#t of todos; #i=index" [model]="t" [index]="t"></todo-cmp>

придется писать вот это:

<template ngFor [ngForOf]="todos" #t="$implicit" #index="i">
  <todo-cmp [model]="t" [index]="i"></todo-cmp>
</template>


Тут меня пугает очередная непонятная переменная $implicit))
Нет-нет, вы не поняли, я говорил лишь про view-layer. Что меня ужаснуло в первом ангуляре и от чего так и не избавились во втором — это изобретение своего собственного неочевидного синтаксиса шаблонов.

В качестве примера достаточно взглянуть на ngOptions: само существование такой директивы заставляет насторожиться.
«Это же простая итерация по массиву объектов! Зачем она вообще?» — спросит реактовод.
«А затем, что иначе вы не сможете в значение option передать что-то кроме строки!»
«Ну, знаете ли...»

Или еще один пример (о котором я писал выше) про передачу параметров в колбэк директивы, отмеченный амперсандом.
Для этого надо вызвать ее с объектом в качестве параметра, ключи которого магическим образом превратятся в переменные, доступные в скоупе (js-скоупе) этого колбэка…
Я перечитывал это раз 10, потому что просто не верил своим глазам.
«Какого хрена вообще?!» — спросит реактовод.
«Ну, потому что по-другому сделать не получилось...»
«Ну, знаете ли...»
Да есть у вас и if-ы, и switch-и, только их использовать надо так, чтобы читаемость не страдала. Хотить switch — запихните его в getColorInHex и все.
Вот вам бы как раз я по рукам-то и дал)

Пример 1:
return (
  <nav>
    <Home />
    {loggedIn ?
       <LogoutButton />
       :
       <LoginButton />
    }
  </nav>
);

… а в большинстве случаев лучше даже так:

render() {
  const { isLoggedIn } = this.props;

  return (
    <nav>
      <Home />
      {loggedIn ?
        this.renderSomething()
        :
        this.renderSomethingElse()
      }
    </nav>
  );
}

renderSomething() {
  return (
    <LogoutButton />
  );
}

renderSomethingElse() {
  return (
    <LoginButton />
  );
}


Пример 2:
const COLORS_IN_HEX = {
  red: '#FF0000',
  green: '#00FF00',
  blue: '#0000FF'
};

render() {
  const { color } = this.state;

  return (
    <section>
      <h1>Color</h1>
      <h3>Name</h3>
      <p>{color || 'white'}</p>
      <h3>Hex</h3>
      <p>
      {this.getColorInHex(color)}
      </p>
    </section>
  );
}

getColorInHex(color) {
  return COLORS_IN_HEX[color] || '#FFFFFF';
}


Вот она — вся МОЩЬ JS в HTML!)
Я не про конкретно ngIf, а про дивную звездочку вначале, которая делает вообще черт знает что.
Ребят, я сам из реактоводов, поэтому сильно ногами не пинайте. Недавно, в силу остоятельств, пришлось активно курить первый ангуляр и периодически, по мере продвижения по developer guide, у меня на заднице шевелились волосы. Честное слово!

Большинство этих моментов было связано с шаблонами (и самый ужасающий из них, это когда я читал про передачу параметров в колбэк директивы, отмеченный амперсандом) и поэтому, наткнувшись на эту статью, с любопытством ее открыл в надежде на лучшее.

Ну что я могу сказать: уже сильно лучше, но направление так и осталось неверное. Ну реально, ребят, неужели никому из вас не кажется, что *ngIf — это ужасающе адский костыль, а присутствие таких вот вещей как раз и говорит о фундаментальных архитектурных просчетах…
Зачем мне тыкать в картинку? Это уже не поиск а просмотр объекта.

Приглянулась превьюшка — тыкнул в нее, чтобы рассмотреть. Не понравилось — тыкнул в другу. По-моему, самый настоящий поиск.

Найдите 10 отличий: www.google.ru/images?q=мороз

Вот незадача, и эти все у гугла слизали…

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity