Как стать автором
Обновить

Четыре уровня одностраничных приложений, о которых вам нужно знать

Время на прочтение 14 мин
Количество просмотров 26K
Всего голосов 35: ↑30 и ↓5 +25
Комментарии 33

Комментарии 33

Для авторов одностраничных приложений предусмотрено 4 одноуровневых котла в аду.

Почему?

Хотя бы потому, что одностраничные приложения ломают привычный способ работы с вебом, создавая неудобства для пользователей.

Ломают привычный способ работы не сами приложения, а кривая их реализация. Но конкретно к описанной в этой статье архитектуре это не имеет никакого отношения.

Ломают привычный способ работы не сами приложения, а кривая их реализация

В этом и проблема. Если часто реализация отказывается кривой, значит, что-то не так с идеей?


Это как множественное наследование в C++ — штука мощная, но из-за криворуких программистов за использование множественного наследования бьют по рукам всех.

Прямой связи "пишем SPA" — "ломаем удобство" нет, зато есть связь "много кода" — "легче что-то испортить".


По такой логике, не нужно писать большие проекты вообще, неважно сайт там или веб-приложение.

По такой логике, не нужно писать большие проекты вообще, неважно сайт там или веб-приложение.

Ну вообще-то да. Для написания подобных проектов нужна соответствующая квалификация, а не "ыыы, заюзаю новый крутой фреймворк и всё будет зашибись".

Возвращаемся к изначальному вопросу этого треда: Почему для авторов одностраничных приложений предусмотрено 4 одноуровневых котла в аду?


Не для криворуких сайтописателей, а конкретно для авторов приложений. Почему?

Потому что конечному пользователю нет дела, что стало причиной некомфортной работы с сайтом: криворукие сайтописатели или же технология написания сайтов.

Но зато пользователь видит, что кривости среди одностраничных приложений больше, чем среди традиционных сайтов. И делает вывод, что проблема в технологии, а не криворуких программистах.

Вот навскидку несколько сервисов, которые сделаны как типичные SPA, но при этом все работает нормально.



Но зато пользователь видит, что кривости среди одностраничных приложений больше, чем среди традиционных сайтов.

По моей выборке пользователь ничего такого не увидит. А какие у вас есть примеры плохо сделанных SPA?

Вот навскидку несколько сервисов, которые сделаны как типичные SPA, но при этом все работает нормально.

Да, это хорошие примеры:


  1. Загрузка быстрая.
  2. Нормальная работа с History API.
  3. Есть возможность открывать ссылки в новом окне.

Хороший SPA — это когда пользователь, работающий с сайтом, даже не замечает, что сайт — SPA.


А какие у вас есть примеры плохо сделанных SPA?

https://www.tinkoff.ru/
https://mail.google.com/
https://mail.yandex.ru/
https://drive.google.com/

Про быструю загрузку ничего сказать не могу, "быстро" – слишком субъективное понятие.


Работа с History API во всех приведенных вами примерах работает как надо. Url при кликах обновляется, перезагрузка страницы приводит туда же где и был до этого.


Открытие ссылок через ctrl+клик работает и в Gmail, и в Yamail. Google Drive и Тинькофф переходы на новую страницу блокируют. Им незачет.


В общем, ситуация все еще не выглядит достойной котла в аду.

Открытие ссылок через ctrl+клик работает и в Gmail, и в Yamail.

В Gmail не работает открытие по среднему и правому кликам, по Ctrl + клик — открываются только письма, но не элементы меню.


Yandex Mail — долгая загрузка при открытии в новой вкладке + перехват правого клика.


В общем, ситуация все еще не выглядит достойной котла в аду.

Ну почему же?


Одно радует: современные технологии создания SPA эволюционируют в лучшую сторону.

Понятно, значит повезло мне, что мой способ с ctrl+click поддерживают, хотя другие варианты нет. Хорошо, буду иметь в виду на будущее.

mobile.twitter.com

Вот с этим не соглашусь. Ненавижу идиотскую моду с бесконечной простыней. Она глючит, скролл работает тупо, продолжить просмотр нереально. Вот создатели простыней должны гореть в аду.

Бесконечный скролл бывает и на обычных сайтах, и на одностраничных. Это отдельная тема для холивара, здесь она не при чем.

Это как он на обычных сайтах?
Да и в чем тогда «хорошесть» твиттера?

Например, pikabu.ru — это же обычный сайт? А бесконечный скролл там есть.

одностраничные приложения ломают привычный способ работы с вебом, создавая неудобства для пользователей.

Скажите, вам кажется, что авторы этой документации должны гореть в аду за то, что сломали привычный способ работы с вебом и создали SPA вместо обычного сайта?

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

Место в аду — скорее для разработчиков веб-стандартов зарезервировано. Все эти хаки — SPA, транспиляция, и прочий CSS in JS — они не от хорошей жизни, без этого сложную аппу просто не сделать. Так что разработчики под веб — и SPA, и обычных — скорее по статье мучеников пойдут на великом суде.
Скажите, зачем так сложно? Читая код, меня охватывает ужас. Т.е вместо простого решения задачи вы делаете кучу обстракций ради простого -> взять данные из точки А и передать в компонент B.

Скажите, зачем настолько усложнять фронтенд логику?

Потому что при большом количестве фич с течением времени, начинается ад из-за отсутствия архитектуры

Я согласен что это излишне для мелких приложений, но подумайте о веб-приложения уровня Enterprise, и я считаю вы поймете к чему такие сложности на фронтенде.

PS: отличный перевод статьи! особенно в дополнению к medium.freecodecamp.org/scaling-your-redux-app-with-ducks-6115955638be приходит виденье как хорошо спроектировать архитектуру фронтенда на годы

А зачем такие абстракции делают на бекенде? Сильно упрощая, там же тоже "получить данные по эндпойнту А и передать в хранилище B".


Одностраничные приложения стараются отвязать от сервера, перенести логику на клиенсткую сторону. Кода становится больше, нужно его правильно организовывать.


В этом примере, где у вас только одна сущность Article, это не очевидно, но когда таких сущностей десятки, правильное распределение кода по иерархии приходит на помощь.

Презентационные компоненты знают о домене и сервисах. Так быть не должно.


// ArticleComponent.js:

import type {Article} from "../domain/Article";
import * as articleUiService from "../services/ArticleUiService";

Почитайте Дэна Абрамова https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0. Он определяет чёткие признаки, того чем Контейнеры о Компонентов отличаются.


// ArticleContainer.js:

import {articleStore} from "../store/ArticleStore";

Для серьезного проекта это тоже неуместно. Получается, что articleStore это глобальный объект. И это работает только потому, что один браузер — один инстанс store. Если захочется, сделать Server Side Rendering, то придется весь код выбрасывать. Ибо там один инстанс сервера — множество инстансов store. Рекомендуется для пробрасывания store использовать Context API .

Ещё вот это антипаттерн:


<button onClick={() => likeArticle(article)} />

На каждый рендеринг компонента создается новая функция, и изменения доходят вплоть до настоящего DOM браузера, а это дорого.

Как правильно?

Нужно создавать заранее замкнутые на props колбеки и дальше уже их всем кому надо прокидывать.
В React-Redux из коробки есть connectAdvanced для таких вещей https://github.com/reactjs/react-redux/blob/master/docs/api.md#examples-1

Так медленно не создание новой функции. Медленно отрывать от DOM узла одну функцию и всаживать другую.
Инлайн объявление объектов и функций является дурным тоном, потому что из-за них могут ложно сработать проверки в методах componentWillReceiveProps и shouldComponentUpdate.
Простые вещи должны оставаться простыми.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий