All streams
Search
Write a publication
Pull to refresh
19
0
Павел Богатырёв @PFight77

Web-developer

Send message

Функции, но не шаблоны HTML. Я привел аргументы выше, почему именно HTML нельзя сокращать до одной строчки.


В этом беда ReactJS, он рассматривает формирование HTML как алгоритм (часть JavaScript), а не как построение по шаблону. Отсюда и маленькие функции, как Вы верно заметили.

Обе крайности плохо. Плохо когда один большой монолит, но и плохо когда весь html разбросан по строчке в произвольном порядке по коду.
Я, как уже писал, сторонник компонентов среднего размера — достаточных для редуцирования сложности, но при этом не на столько маленьких, чтобы вместо декларативного шаблона мы получили набор императивных инструкций.

От того, что Вы записали в одну строчку код более красивым не стал: )) И да, на практике объявлять кучу переменных в начале функции лично мне всегда лень. И всем моим коллегам. Да к тому же, появляется лишняя степень индирекции, чтобы понять откуда берется значение необходимо это отследить. Лишняя сложность для понимания и отладки.


Зачем вам нужно знать, каким станет html полностью?

Затем, что, собственно, это и есть цель любой подобной технологии — породить html. Есть результат который у меня в голове, и есть средства, которыми я его добиваюсь.


Ну а если без громких фраз:


  1. Прежде всего для верстки. К сожалению, css не так прост. Часто требуется добавлять всякие врапперы, менять порядок элементов и прибегать к прочим подобным приемам, чтобы добиться нужного вида и поведения макета. Часто для правильной верстки отдельной области нужно контролировать отдельные ее части. Поэтому для верстальщика важно видеть html целиком, и иметь возможно легко его менять. Плохо здесь именно разбиение шаблона даже в рамках одного компонента, с разбиением на дочерние компоненты еще можно смириться. Хотя я всегда предпочитаю не плодить слишком много мелких компонентов. Я считаю, что под-компонент есть смысл выделять, если он содержит хотя бы десяток строк html и сколько-то логики (за исключением простых, часто используемых stateless).
  2. Для отладки. Допустим, тех же багов в верстке. Я нахожу через DevTools в браузере проблемное место в html, и хочу найти код, где данный html рождается. В react это становится проблемой, т.к. код разбросан по куче мелких функций. Хорошо если find all по имени класса получится.
  3. Для простоты восприятия. Сколько бы мы не говорили про модульность и гибкость, это все вспомогательные вещи. Главное — результат. Если мы генерируем html, результат — картинка в браузере. В конечном счете я хочу получить конкретный макет, конкретный вид сайта. И я хочу понимать, как эта картинка сформируется. Дробление шаблонов в React осложняет это понимание.
Основная беда JSX в том, что он страшно выглядит как шаблон. Он позволяет делать все что угодно, но простые вещи — if, for в нем смотрятся не очень. Вот примеры для сравнения, React и Angular2:

Условие:
<div>
    { this.state.loading  &&
        <div class="loading-icon"> </div>
    }
</div>

<div>
    <div class="loading-icon" *ngIf="loading"> </div>
</div>


Цикл:
<ul>
    { this.state.items.map(item => 
        <li >{item.name} </li>
    )}
</ul>

<ul>
    <li *ngFor="let item in items" >{{item.name}}</li>
</ul>

Причем, для цикла в реакте еще рекомендуют map выносить в отдельную функцию, чтобы совсем запутать свой шаблон. В англуяре шаблон выглядит как html, близкий к тому, что получится в браузере. Реактовский шаблон, как правило, далек от конечного результата, хотя бы потому, что куски html часто оказываются разбросаны по функциям, порядок которых определяется порядком их вызова (соответственно, он может отличаться от порядка объявления в коде). Так что, представить, каким станет html в реактовском компоненте — не так просто.
Пока читал Ваш комментарий, пришла такая мысль: что если реализовать синглтон на уровне фабрики? Ну, то есть, инжектим везде через { useFactory:… }, а в фабрике соответственно, не создаем каждый раз новый объект, а возвращаем однажды созданный. А чтобы никто не внедрил сервис в обход фабрики сделать проверку уже в рантайме, определив каким-то образом, откуда вызыван конструктор сервиса — из фабрики или как-то еще (например, опциональный параметр).
Рекомендуется использовать свойство flex, вместо задания компонентов по отдельности, т.к. чаще всего эти три свойства (flex-shrink, flex-grow, flex-basis) нужно задавать вместе.
Согласен, только трудно поместить все, не нарушив логику повествования. Добавил немного, что относится непосредственно к теме статьи.
Добавил в статью про проценты.
Спасибо за ссылки! Я когда задался специально целью найти хоть какое-то упоминание min-width: auto потерпел неудачу: ) Здорово, что хоть кто-то об этом написал.
Да, еще как подсказал monochromer, white-space: nowrap делает минмальную ширину текстового содержимого равной ширине текста в одну строчку.
Ох, только сегодня два часа потерял на фикс багов, воспроизводящихся исключительно в Safary. Причем, один из них воспроизводился только на ipad (на iphone все ок), и только в portrait ориентации. Люблю Safary.
В контексте этой статьи в том, что длинные слова будут растягивать flex-элементы, вместо того чтобы переносится по break-word.

По спецификации auto «is the smaller of its content size and its specified size.» Минимальная ширина для текста — ширина самого длинного слова, что приводит к таким плачевным последствиям. Однако, если поместить внутрь flex-элемента картинку, или какой-нибудь широкий блок, то получим тоже самое.

Ну и вообще, даже если не брать крайние случаи, просто нарушается логика, заданная во flex свойствах. Например вот здесь элементы имеют одинаковые basis, shirk- и grow-факторы, и по идее, должны быть одинаковой ширины. Но из-за min-width: auto левый занимает больше пространства. Это я называют «контр-интуитивно».
12 ...
8

Information

Rating
Does not participate
Location
Орел, Орловская обл., Россия
Registered
Activity