Уточню чтобы никто не обманывался, веб сокет имеет свои проблемы и нагрузка на сервер и клиент меньше лишь в условиях потоковой или высокой частоты передачи данных

Надеюсь, что ответил на ваш вопрос 🙂

Привет всем Друзья помогите понять одну вещь До этого делал сайты в основном лэндинги и корпоративные, работал с cms-ками WordPress, OpenCart, использовал обычную связку html+js+jQuery+php, потом пришел в одну компанию где собственно сейчас и работаю, здесь уже занимаюсь автоматизацией бизнес процессов, здесь работает один мужик лет 40, он познакомил меня с сервлетами и Java в целом, поэтому сейчас использую связку html+js+jQuery+php(просто как прокладка между js и сервлетами)+servlet Так вот с ним я как-то пропустил бурное развитие фрэйемворков, сейчас начал изучать, из-за популярности выбрал angular И я так и не могу понять для чего он нужен, как я понимаю фрэйемворк должен облегчать жизнь программисту, а я сейчас изучая не вижу ничего лёгкого, да сам подход там правильный, модульная архитектура и все такое, но зачем это использовать на обычных сайтах, почему такая шумиха над этими фрэйемворками или что сейчас все разрабатывают такие крупные ресурсы как habr или Facebook Или может ресурс для изучения выбрал неправильный, изучаю по видео с канала webdeveloperblog, он больше просто показывает что есть а ангуляр и как это пишется но сам по-моему не особо понимает как это работает, в документацию пока не лезу потому что хочу понять основы

самая главная причина по которой существуют фреймворки это синхронизация ui c состоянием, вот даже статья есть на эту тему (заодно и объясняет почему веб-компоненты не смогут заменить фреймворки) - https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445 или ее перевод на хабре https://habr.com/company/ruvds/blog/353074 а всякие сервисы, взаимодействия с сервером, роутинг, di и т.п что есть в ангуляре уже не так важно

самая главная причина по которой существуют фреймворки это синхронизация ui c состоянием, вот даже статья есть на эту тему (заодно и объясняет почему веб-компоненты не смогут заменить фреймворки) - https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445 или ее перевод на хабре https://habr.com/company/ruvds/blog/353074 а всякие сервисы, взаимодействия с сервером, роутинг, di и т.п что есть в ангуляре уже не так важно

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

Не совсем так, там есть два слоя, которые нужно разделить и понимать почему они появляются. Первый слой как уже выяснили это биндинги(привязки). А второй слой это стейт-менеджеры и появились они потому что решают проблемы первого слоя) Но тут надо объяснить по порядку. Для начала первый слой - мезанизм привязок (биндинги) это тот самых механизм который позвоялет указать в шаблоне <div>{someObje.field1.field2.value}</div> и фреймворк автоматически каждый раз когда будет менятся значения выражения "someObje.field1.field2.value" будет изменять ui чтобы сихронизировать его со значением выражения (правда не все фреймворки предоставляют возможность указать любые жс выражение, некоторые только подмножество) Соотвественно кроме выражений также должна быть возможность указать условные выражения, в зависимости от которых вывести тот или другой шаблон <div> {someObj.flag ? <div> .... <div> : <div> .... </div> } </div> И также возможность указать циклы по данным <div> {someObj.someArr.map(item=> <div> {item.value} .... </div> )} </div> Дальше уже идут фичи которые относятся к компонентной модели и механизму взаимодействия компонентов (разбиение на компоненты, передача им данных (пропсов), передача динамических пропсов (не все фреймворки поддерживают), функций-обработчиков (или передача и обработка событий), передача компоненту вложенной верстки (слотов) и даже скоуп-слоты (возможность получить от компонента данные при передаче слота) Некоторые из этих фич поддеживают веб-компоненты поэтому они могут заменить эту часть фрейморков (но полностью заменить фреймворки не смогут так как они не предоставляют тот самый механизм привязок) Эти биндинги и есть первый слой(и самый главный), а второй слой - это уже менеджеры состояния (всякие flux, redux, mobx) и появились они из-за ограничения фреймворков которые не поддерживают (или слишком медленные для этого) возможность сихнронизировать изменения состояния компонентов которые рендерят одни и те же данные Представим сложное spa-приложение которые напоминает рабочий стол - можно отрыть много окошек внутри которых будет отображаться список файлов или какой-то другой информации. И получается что один и тот же файл может одновременно отображаться в разных компонентах, и при изменении его имени нужно сихронизировать ui во всех компонентах-окошках которые оторбажают эти файлы. Так вот - некоторые фреймворки например react предоставляют механизм сихронизации ui c состоянием только внутри компонента (через вызов setState) а согласно примеру выше нужно сихронизировать состояние между компонентами. Точнее реакт все-таки поддерживает сихронизацию между компонентами - можно сделать общее состояние во внешних жс-объектах и передавать компонентам и рендерить информацию из них а при изменении любых данных где-то глубоко в приложении можно просто вызывать функцию sync() которая выполнить перерендер всего приложения (const sync = ()=> ReactDOM.render(<App/>, rootEl) и это решит задачу. Но это довольно медленный способ (потому что происходит сихнронизация всего приложения) и на большом приложении будет тормозить и намного быстрее было бы было бы выявить список нужных компонентов и выполнить сихрноизацию ui с состоянием на отдельных компонентах (в реакте это вызвать setState()) вместо того чтобы выполнять сихронизацию абсолютно всех компонентов приложения. Вот поэтому и появились стейт-менеджеры (flux, redux, mobx и др) которые решают как раз эту задачу. То есть причина их появляения не сколько в том что они добавляют какие-то удобства (которые можно получить и без них) сколько в том что они решают проблему тормозов фреймворка который неспособен быстро выполнить сихронизацию ui с состоянием сразу всего приложения на каждое малейшее изменение данных.

Детали работы отличаются

общая суть одна и та же, нужно сихнронизировать ui с состоянием, но из-за того что фреймворки не позволяют на каждое изменение данных быстро выполнить сихронизацию ui с состоянием сразу всех компонентов, собственно и появились стейт-менеджеры (flux, redux, mobx) которые трекают какие компоненты каким данным соотвествуют чтобы при изменении данных выполнить обновления только нужных компонентов

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

я же выше написал, да они поддерживают частичные обновления данных но внутри компонентов, а если требуется синхронизировать данные между компонентами (один и тот же файл отображается в разных компонентах-окнах и при изменении имени файла нужно обновить все компоненты-окна которые отображают этот файл) то это уже требует выносить данные файлов в некоторое общее состояние (чтобы из изменения одного файла увидели все остальные компоненты). Обычно это состояние выносят в родительский компонент но рано или поздно при расширения функционала оно окажется внутри корневого компонента и соотвественно малейшее изменение данных вызовет перерендер корневого компонента (что соотвествует перерендеру всего приложения), но помимо этого еще появляется проблема проброса пропсов между компонентами и проще уже взять и вынести это состояние извне компонента - export const state = { ... } и в нужном компоненте заимпортить и отрендерить нужные данные из этого объекта. Таким образом решается проблема проброса пропсов, ну а чтобы сихронизировать с ui то достаточно просто вызвать перерендер всего приложения (в реакте это ReactDOM.render(<App/>) Получается примерно так export const appState = {files: []}; ... import {appState} from "./state" ... onClick = ()=>{ appState.files.push({name: "", ...}); sync(); //вызывает <ReactDOM.render(<App/>, el) } ... И таким образом импользуя только нативные жс объекты мы можем удобно работать с состоянием без стейт-менеджеров. Но только до тех пор пока приложение не разрастется и вызов перерендера (сихронизации) всех компонентов приложения не окажется медленным. Тогда и появляется необходимость в стейт-менеджере которые будет трекать какие данные каким компонентам соотвествуют чтобы вызвать перерендер только нужных компонентов а не всего приложения

И вот где здесь косяк?

Прописываешь нужному event.target-у какой-то класс, и делаешь проверку let $item = $(ev.target); if ( !$(ev.target).hasClass('<название класса>') ) { $item = $(ev.target).closest('<название класса>') }

Работает, но такая херня получается, что ev.target может быть как сама кнопка, так и <i> в кнопке. Как этого избежать?

Народ, вопрос на миллион. Если див отцентрирован как "position: absolute; top: 50%; left: 50%; transform: translateX(-50%) translateY(-50%)", то у его дочерних элемнетов в Хроме вообще никак по-человечески анимацию прозрачности не сделать ? Сейчас воюю с этой хренью, текст размывается и все во время анимации. Даже во время дилея перед анимацией .-.

пиплы, ошибка влидации это какой HTTP код лучше поставить? 400?

Вот старая статейка на эту тему https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

422

Выложи код где нибудь.

Наводишь на любую из кнопок в Хроме и наслаждаешься блюром, пока идет анимация.

чесгря не понял, в чем проблема. на примере кнопки clear

Есть 2 инпута с выпадающим календарем на разных станицах сайта, стили у них тоже должны быть разные. Подключил datepicker через jquery ui. Стили календаря на одной странице я перебил. На второй станице применяются те же стили, что и на первой странице станице. Как их изменить? Сам выпадающий календарь создается в боди без всяких вложений, так что через вложенность никак не обратиться. Классы для выпадающего календаря на разных страницах тоже идентичны, так что через классы тоже нельзя разные классы прописать для разных страниц. Какие идеи?

полагаю что сменить главный класс, от которого и вязать стиль календаря?

Так не прокатит. У инпута есть класс .calendar, инициализация привязывается к классу инпута. Но сам выпадающий календарь создается со своим классом ui-datepicker прямо в боди. Я этот класс нигде не задаю, он сам его берет по дефолту на всех страницах

Так не прокатит. У инпута есть класс .calendar, инициализация привязывается к классу инпута. Но сам выпадающий календарь создается со своим классом ui-datepicker прямо в боди. Я этот класс нигде не задаю, он сам его берет по дефолту на всех страницах

в таких штуках обычно есть свойство типа "containerClass", где можно задать произвольную строку и плясать от нее

учитывая что там jQuery UI, инфа 100, кастом класс .datapicker присваивается из нее.