Чтобы, например, при компиляции шаблона компилятор сразу бил по рукам, если мы пытаемся передать неитерируемый объект в <c:foreach items="">. Или при вызове неправильного шаблона из сервлета. Опять-таки, не пришлось бы передавать множество нетипизированных параметров через setParameter.
Одно из ключевых отличий JSP и JSF как раз в этом моменте.
JSP станица компилируется в сервлет либо при первом обращении либо заранее, а JSF - нет. В JSF прям жесткое разделение на шаблон и логику. Шаблон валидируется как XML, код лежит отдельно.
Между ними Expression Language (EL) - язык выражений, достаточно простой чтобы не быть проблемой.
Вообщем если не впадать в маразм и не насиловать инструмент, то вполне можно обходиться минимумом логики в шаблонах.
Опять-таки, managed bean выдёргивается тупо по имени, и какой у него интерфейс — абсолютно неизвестно до запуска страницы.
Но это что касается полноценных страниц. И на фронтенде в принципе со страницами тоже можно было сделать аналогично через тот или иной DI. А как быть с отдельными компонентами?
managed bean выдёргивается тупо по имени, и какой у него интерфейс — абсолютно неизвестно до запуска страницы.
Я ж говорю: без фанатизма.
Конечно же там куча ограничений, что класс этого бина должен быть публичным, его инстанциация должна происходить силами контейнера и еще много всякого.
Как только доходит до усложнения - пиши пропало. Поэтому простоту необходимо поддерживать всеми силами. Сложное сделать просто, простое - сложно.
Отдельные компоненты в JSF это тоже комбинация из шаблона и кода, с точно таким же разделением.
Но в рамках конечного проекта их обычно не делают, если только это не нечто монструозное.
А чем лучше такой подход? По факту у тебя все равно шаблон включает хоть минимальный, но код. На реакте заметно больше преимуществ - все валидируется, эффективно ререндерится при изменении пропсов, сразу же вешаются все нужные обработчики.
Кстати, а как в JSF делается родительский шаблон, который отвечает за общие части разных страниц?
Наверное наиболее грамотным способом из всех виденных:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
template="./template.xhtml">
<ui:define name="top">
Top Content
</ui:define>
<ui:define name="left">
Sidebar Content
</ui:define>
<ui:define name="content">
Main Content Goes Here!
</ui:define>
<ui:define name="bottom">
Footer goes here
</ui:define>
</ui:composition>
Те общий шаблон лежит в отдельном файле и указывается в заголовке страницы (фактически в метаданных). В самой странице набор именованных блоков, контент которых вставляется в общий шаблон:
Преемущество в том что вот такое на самом деле не надо. Ты мыслишь как разработчик, ставя технологию выше задачи.
Если смотреть от задачи, то окажется что не существует необходимости в постоянном изменении полей всегда и везде.
Суть в том, что компоненты Реакта не описывают только страницы, а для промежуточных компонентов строгая типизация — это хорошо. Точно так же, как строгая типизация в Java — это хорошо.
а для промежуточных компонентов строгая типизация — это хорошо
Вот это тоже смешной момент: получается что на бекэнде тенденция идет к отказу от строгой типизации в сторону duck typing и lazy evaluation, а на фронте ровно наоборот - идет переход от динамической к строгой.
Т.е ровно то за что на бекэнде не любят джаву - за это же на фронте обожают тайпскрипт.
Я бы не сказал, что на бекенде прям тенденция. Даже питон и пхп внедряют средства статического описания и проверки типов. И разве есть повальное бегство с джавы/шарпа на динамическую типизацию в суровом энтерпрайзе?
Rust type system allows arbitrary amount of dynamic typing. If you want, you can write totally dynamic everything, and get all type errors in runtime (there is a dyn keyword for this).
Or, you can completely stop using any dynamic features and get all typechecking in a compile time.
Вообщем это опять такое современное «да но нет» или «вставить но на полшишечки».
Не хочу снова погружаться в обсуждение этих теологических вопросов, потому как сейчас опять набегут «идолопоклонники» и начнут всех поучать как правильно.
Ну как-то странно: фронт у тебя занимается вычислениями у кого какой выходной когда. ИМХО, фронт должен только взаимодействовать с пользователем, а логику и расчеты – в зад
Создание одного элемента в дереве требует собственно создания элемента через createElement, множества вызовов setAttribute, множества вызовов addEventListener, затем встраивания элемента в дерево.
Ну так оберни в удобный тебе способ. JS позволяет
Наконец, одна из важнейших фич: даже в WebComponents нельзя удобно делать динамические и быстрые for и if по элементам.
Ну когда создаешь – запоминай нужные тебе в массив. Или вообще как и что там тебе удобно
Мое недоумение только от того что кому-то мало того что предоставляет ЖС. Да делай что хочешь и при том никакой низкоуровневой запары. Ну да ладно: это, видимо, вкусовщина
Ну, вот, в частности реакт эти вопросы и разруливает.
Ну я приблизительно так и представляю, но все эти вещи актуальны и для всего остального программирования, однако, все в один голос твердят что в вебе без реакта и ему подобных жизни нет, а в каком-нибудь системном программировании что-то как-то все как писали руками так и пишут. (или может я опять в танке)
К чему тогда вопросы «объясни в двух словах зачем нужна Ё, когда уже есть ЙО»?
все в один голос твердят что в вебе без реакта и ему подобных жизни нет
Только в одной этой теме есть сторонники прямо противоположного мнения. Нет «одного голоса», а есть тренды, появится что-то ещё интересное и будут твердить и про него. Вот, даже дошли до трендовых рекомендаций не использовать реакт, а уже пользоваться фреймворками на его основе.
К чему тогда вопросы «объясни в двух словах зачем нужна Ё, когда уже есть ЙО»?
Да потому что никто и никогда не объяснил никак, кроме как общими фразами. Совсем общими, настолько общими – что они ко всему программированию применимы.
Ты прав, конечно, говоря, что если бы я хотел – сам бы разобрался. Оно мне не особо надо, я веба почти не касаюсь, просто, когда касался – одурел от возможностей и до сих пор недоумеваю какие-там вообще могут быть проблемы при прямых руках.
Ладно, молчу. Бог с ним, с вашим реактом. Спасибо за ответы
В описанном ТЗ не предусматривается особых вычислений на клиенте. Автораскладка людей по дням может быть реализована и на бекенде. Но на фронте остаётся возможность отредактировать график.
Сначала написать тупую обёртку, затем решить, что в некоторых случаях пригодится и отложенный рендеринг компонента. Вот тебе и виртуальный DOM из React. Ведь его JSX-синтаксис — это на самом деле вызовы функций:
Ну когда создаешь – запоминай нужные тебе в массив. Или вообще как и что там тебе удобно
Суть в том, что не стоит пересоздавать элементы в списке, если он уже созданы — это дорого, а нужно только добавить или удалить то, что изменилось. И для этого в самом JS есть только низкоуровневые appendChild и insertBefore. Например, можно сохранять массив ранее выведенных элементов, затем сравнивать его с новым и находить точки изменений. Будет та же самая реконсиляция, что и в React.
, а нужно только добавить или удалить то, что изменилось.
Тут можно нехило так выстрелить себе в ногу, поскольку нет простого способа понять состояние каждого элемента.
Может поменяться порядок элементов, может быть обновление отдельных полей, часть может исчезнуть, часть появиться - на уровне самих данных, полученных с сервера а не DOM элементов.
Поэтому временами логика «удалить все и заново сгенерировать список элементов» является оптимальной, пусть и не с точки зрения скорости то с точки зрения верифицируемости.
Тут можно нехило так выстрелить себе в ногу, поскольку нет простого способа понять состояние каждого элемента.
Ты же сам знаешь, как эти варианты решают фреймворки, в частности, React и Vue.
Поэтому временами логика «удалить все и заново сгенерировать список элементов» является оптимальной, пусть и не с точки зрения скорости то с точки зрения верифицируемости.
А если на компоненте для каких-то целей сделана обработка mount и unmount, то это будет ещё тяжелее.
как эти варианты решают фреймворки, в частности, React и Vue
Нет, видимо ты из тех редких программистов, доживших до своего опыта, которых никогда в жизни сильно не били.
Представь что твоя зарплата зависит от рендера компонента на реакте - готов так подставиться?
Но полагаю этого мало, ладно. Представь что ты гражданин США и компонент на реакте будет решать сколько тебе придется платить по страховке в клинике: $5000 или $500000. Причем даже если произойдет ошибка - судиться с клиникой тебе не под силам - денег нехватит.
Готов сиграть в такую игру когда на кону собственное очко?
Даже с большим успехом зарплата/счёт могут зависеть от бекендного кода, написанного на нетипизированном языке. Или тупо из-за алгоритмической ошибки на бекенде.
Вообще-то вопрос был другой и вполне конкретный, но твой ответ крайне показателен: даже зная что я не смогу создать условия для подобной проверки - ты до такой степени не веришь в собственный инструмент, что не готов подписаться под собственным решением даже виртуально.
Это все что вам нужно знать про Реакт в частности и MVVM концепцию в целом - это просто игрушка, с которой будут «играться», разумеется за ваш счет.
Я мало знаю о современном фронтенде и тем более о React, поэтому не совсем понимаю дискуссию. Но у меня вопрос: не мог бы ты развернуть мысль с примером про страховку? С твоей точки зрения неприемлемо то, что доменные правила приводятся в действие кодом на клиенте в принципе? Или проблема именно в React? То есть в составе React есть какой-то модуль/инструмент у которого проблемы с корректностью? Или у него недетерминированное поведение? Или поведение этого инструмента не было нормально формализовано?
Реакт работает через события, те ты не можешь что-либо отобразить без отработки события. Помимо событий, в реакте есть биндинги полей: ты объявляешь набор полей, вставляешь их в шаблон а затем присваиваешь им значение - в этот момент отрабатывает проверка состояния и если фреймворк видит что поле поменялось - перестраивает DOM. Только после этого ты визуально на экране видишь изменения.
Это все упрощенно, в реальности все куда сложнее, особенно если знать что реакт работает не с реальной DOM моделью а со своей виртуальной - shadow DOM.
Отсюда получается что есть очень сложная логика с момента получения значения $5000 с сервера и до его отображения в браузере.
Поэтому для важных данных все также стараются показывать готовый html, сгенеренный на серверной стороне. Ну я стараюсь по крайней мере.
Но появляются новые точки отказа, особенно когда часть фронтендной логики оказывается на бекенде (отображение форм) и фронтенде (заскриптованные контролы).
Не сильно стало яснее, но всё равно спасибо. Ну то есть он должен по изменениям в input сформировать и применить такой набор изменений, который переведет дерево то же состояние как если бы input изначально был таким. Твоя критика наводит на мысли, React это видимо какой-то полукривой типа дата-байндинг, который в силу каких-то объективных причин incomplete, поэтому некоторых гарантий дать не может. В результате сложность переместилась в ментальную область и вероятность ошибок возрастает.
Это все больше философский спор, из которого точно не стоит делать далеко идущие выводы.
Еще есть интересный момент: банку (как и любой другой финансовой организации) на самом деле выгодны сложные ошибки в ПО, особенно если они приводят к списанию средств в пользу банка.
Поскольку судиться и возвращать средства долго и сложно, далеко не все будут этим заниматься.
Эту же тактику взяли на вооружение операторы большой тройки кстати.
Однако можно протестировать сервер и клиент по-отдельности
Если немного подумать то окажется что эмулировать тестовую среду и окружение близкое к реальному пользователю невероятно тяжело, а синтетика нужна лишь для отчетности и успокоения нервов.
Здесь нет ни «сложных», ни вообще каких-либо ошибок. Только эксплуатация вероятного окружения реального пользователя, у которого, скорее всего, стоит адблок.
Но клиентские программы тоже нужно писать, и это тоже большая точка отказа. Да и на практике получается, что с учётом зоопарка потенциальных клиентских платформ (Windows, Linux, macOS, Android, iOS) и бутылочного горлышка в виде необходимости обновлений клиентов, оказывается, что фронтенд в виде SPA-приложения и, дополнительно, мобильных приложений, — не так уж и плохо.
банку (как и любой другой финансовой организации) на самом деле выгодны сложные ошибки в ПО, особенно если они приводят к списанию средств в пользу банка
Кстати тут хороший момент в том, что если ошибка произошла в пользу банка, то клиенту нужно будет ещё посудиться, чтобы вернуть отобранное по ошибке, а если ошибка произошла в пользу клиента, то банк может или дополнительно списать недостачу, или заблокировать счета, или тоже подать в суд за «необоснованное обогащение». А у банка штат юристов всё-таки будет посильнее. А клиенту выбор интерфейса не предоставляют.
Я вот кстати уже больше полугода вяло воюю с техподдержкой своего банка, у которой из-за ошибки неправильно формируется строка моего адреса проживания. То есть в БД адрес корректен и разложен по разным полям, а бекенд формирует абсолютно кривую строку. При этом они каждый раз отвечают «Работы провели — ошибка исправлена». Так что даже без фронтенда простор для косяков остаётся огромный.