Комментарии 33
Почему?
Ломают привычный способ работы не сами приложения, а кривая их реализация. Но конкретно к описанной в этой статье архитектуре это не имеет никакого отношения.
Ломают привычный способ работы не сами приложения, а кривая их реализация
В этом и проблема. Если часто реализация отказывается кривой, значит, что-то не так с идеей?
Это как множественное наследование в C++ — штука мощная, но из-за криворуких программистов за использование множественного наследования бьют по рукам всех.
Прямой связи "пишем SPA" — "ломаем удобство" нет, зато есть связь "много кода" — "легче что-то испортить".
По такой логике, не нужно писать большие проекты вообще, неважно сайт там или веб-приложение.
По такой логике, не нужно писать большие проекты вообще, неважно сайт там или веб-приложение.
Ну вообще-то да. Для написания подобных проектов нужна соответствующая квалификация, а не "ыыы, заюзаю новый крутой фреймворк и всё будет зашибись".
Возвращаемся к изначальному вопросу этого треда: Почему для авторов одностраничных приложений предусмотрено 4 одноуровневых котла в аду?
Не для криворуких сайтописателей, а конкретно для авторов приложений. Почему?
Но зато пользователь видит, что кривости среди одностраничных приложений больше, чем среди традиционных сайтов. И делает вывод, что проблема в технологии, а не криворуких программистах.
Вот навскидку несколько сервисов, которые сделаны как типичные SPA, но при этом все работает нормально.
Но зато пользователь видит, что кривости среди одностраничных приложений больше, чем среди традиционных сайтов.
По моей выборке пользователь ничего такого не увидит. А какие у вас есть примеры плохо сделанных SPA?
Вот навскидку несколько сервисов, которые сделаны как типичные SPA, но при этом все работает нормально.
Да, это хорошие примеры:
- Загрузка быстрая.
- Нормальная работа с History API.
- Есть возможность открывать ссылки в новом окне.
Хороший 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 эволюционируют в лучшую сторону.
mobile.twitter.com
Вот с этим не соглашусь. Ненавижу идиотскую моду с бесконечной простыней. Она глючит, скролл работает тупо, продолжить просмотр нереально. Вот создатели простыней должны гореть в аду.
одностраничные приложения ломают привычный способ работы с вебом, создавая неудобства для пользователей.
Скажите, вам кажется, что авторы этой документации должны гореть в аду за то, что сломали привычный способ работы с вебом и создали SPA вместо обычного сайта?
Скажите, зачем настолько усложнять фронтенд логику?
Я согласен что это излишне для мелких приложений, но подумайте о веб-приложения уровня 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
Четыре уровня одностраничных приложений, о которых вам нужно знать