Вот Вы просто не понимаете смысл es, но говорите что сфера другая. Энтити, это всего-лишь цикл, но цикл не для массива, а для всего приложения + само название говорит что работа будет происходить не с объектами, а их сущностями. Сейчас мода это виртуальный дом, который можно рендерить на сервере. Но с энтити можно было бы рендерить на сервере + Вы бы не видели разницы в работе с домом. То есть в angular2, реакте и им подобным фраймворкам есть одна большая проблема, все новые приблуды в виде библиотек компонентов, всякие скролы и прочие нужно ещё подогнать под эти фраймворки. А теперь представьте что Вы можете скачать самые красивые и модные компоненты и работать с ними в Вашем фраймворке. И при этом прирост в производительности огромный, особенно для сложных анимаций. А так или иначе эти сложные анимации должны встречаться все чаще и чаще.
И главно что все так же можно писать кастомные компоненты и добавлять в них логику.
в котором ещё куча всего завёрнуто + chai и mocha (тестировщики кода)
только вот весь мир давно использует связку karma + jasmine.. И кто знает какая фигня там ещё присутствует. А если захотите изменить, то придется свой писать..
Сергей Протько: да юзают-то все что им суют и всегда вначале довольны. Но беда начинается тогда, когда императивность сталкивается с безумно-стремно спроектированными фраймворками, как например реакт ( не могу сказать за angular2 ). Вместо того чтобы оттачивать архитектуру фраймворков, люди начинают подстраиваться под симбиоз последних с rx.js, тем самым создавая новые сложности.
Все в js не любят ооп, но почему-то не стремятся к самой совершенной архитектуре предназначенной специально для дисплей листа, а именно entity system.
Люди не знают о ней, те кто знает не хотят постичь её думая что это титанический труд.
Но на деле entity system можно объяснить за десять минут. Это до ужаса просто и до ужаса эффективно. И мало того, это правда очень удобно.
И зная это, лично мне приходится мучится когда я вижу то что от меня будут хотеть, когда я буду с кем-то в команде работать. Мне кажется что я вообще не в состоянии работать на кого-то :)
Вы не хотите статью о entity system написать? Я бы Вам объяснил, а Вы дальше в массы, у Вас это хорошо получается :)
Дмитрий: я тысячу раз свое мнение менял и но последнее говорит о том что любая архитектура которая совместима с реактом, эта та, у которой во главе стоит представление. В тот момент пока я управляю приложением через представление-компоненты все идет ровно. Но представить что с сервера пришли данные-коллекция которые собираются в умном компоненте. Вот Вы собрали и вдруг понадобилось изменить один компонент и понадобилось это сделать по инициативе не реакта, а сервера. С сервера придет запрос по которому Вы можете вызвать любой метод, но не сможете передать в этот метод компонент из реакта. По этому единственно верный способ, опять жахнуть тысячу айтемов в тот же умный компонент и пересобрать все заново. Да, реакт изменит только один элемент, но произойдет это после цикла над айтемами, составлении строки, сравнения строки с первоначальной.
Дмитрий: да, только это не flux. Flux, это неупорядоченная очередь в кассы, в которой кассир принимает строго в известном только ему порядке. Но он не кричит - Иванов, Смирнов, Сидоров, он кричит следующий. И все толпа должна подбежать и назвать свою фамилию чтобы кассир сказал тот ли чел ему нужен или нет. То есть сторы не шлют определенных событий, а шлют одно - change. Если это Вам кажется излишним на каждый change перестраивать все приложение, то Вы можете оптимизировать усложнив все ненужной логикой в shouldComponentUpdate.
Если Вам и это не нравится, то Вы убогий и не адекватный.
я сейчас тоже с ним работаю и делаю не то что делают остальные. И мое мнение что он не предназначен для динамических данных. Это просто нужно быть сбитым поездом чтобы сказать - сначала мы прокидываем все через App, ведь у нас обычные приложения и не страшно что это не совсем положительно сказывается на производительность. А после как прокинули давайте нанем оптимизировать в методе shouldComponentUpdate.
По другому - сломайте себе ногу, а на следующем шаге давайте её лечить.
на самом деле все просто, есть всего-лишь два варианта. 1) Вы делаете так и только так, как написано на офф сайте. Не волнует нравится Вам это или нет. 2) Делаете так как считаете нужным, но при этом подписываетесь под тем, что Вас будут называть неадекватным и не будут хотеть с Вами работать. И не ипет правы Вы или нет, не упаси господь чтобы Вы, простой смертный сказали вслух что реакт это полный трешь. Стадо сразу начнет мычать говоря что где цукерберг, а где Вы.
Сергей Протько: давно лично Вас хочу спросит, Вы rxjs уже пробовали? Просто я пробовал, хочу сказать что это чудо с которым программирование становится просто сказкой, но есть одно НО. Оно состоит в том, что эта библиотека на корню убивает стремление развиваться как архитектору. Все приложения превращаются в некое подобие mvp - тут взял, туда положил, сохранил промежуточный результат, опять что-то сделал и положил туда откуда начинали..
Rou1997: мне не нужны свистелки и перделки, мне хочется полностью кастомизировать интерфейс приложения, которое будет работать везде. Получается что c# этого предоставить мне не может и мне нефиг его учить, так как даже убогий js мне это может гарантировать. разрабатывать сервера это java -> ruby -> python. И вопрос - нахер c#? Если только для приложений для банков, то мне как программисту не хочется такой нудной фигней заниматься.
Сергей Протько: и на самом деле фиг его знает как лучше. Мне нравится простота динамических языков, но типизированные для меня являются зависимостью. Я жить без них не могу. Когда появилась возможность полноценно писать на .ts то писать код стало одно удовольствие, хотя я не могу сказать что мне было сложно на чистом js, вообще ни капельки.
Сергей Протько: модули не в состоянии заменить инъекции, так как предназначены совершенно для другого. Модуль импортирует ссылку. Если я в два файла импортирую ссылку на один объект, то в случаи замены мне придется лезть в эти два файла и менять ссылки. Если же проект воистину большой, то можно угрохать день на их замену. В случаи с инжектором мне нужно лишь в одном месте ссылку поменять. А в место где я буду инициализировать инжектор я импортирую ссылку. По этому модули и инжектор это "пишу код" - "профессионально пишу код". И именно это у меня и вызвало недоумение, как же можно писать код по взрослому и без инжектора..
полная чушь. Вы своими ненормальными мыслями если и делитесь, то делайте это с теми кто Вас уже знает и не воспримет всерьез. Статус в скайпе - значит прячется... А может он в это время с себя кожу снял чтобы подзарядится и продолжит план по захвату планеты земля, а Вы как раз звоните.. Нет?Подумайте над этим.
Сергей Протько: прошу прощение у автора этой темы за то что снова её поднял, но я не смог удержаться :)
Помните разговоры о функциональном программировании? Вот у меня сейчас вопрос возник - а куда тогда зависимости будут инжектиться? То есть вот есть класс, ему в конструктор внедряют зависимости и если не будет свойств, то куда их тогда сохранять и внедрять? Наверняка даже в angular2 в конструктор инъекции производятся?
То что показываю на видео, когда верстают в голом sublime text3 пригодно только для "о, как прикольно". В реальности дизайн приходится не просто рисовать в фотошопе с применением кучи правил, без которых просто невозможно, но и рассчитывать на "листочке" математическую модель.
Вот Вы просто не понимаете смысл es, но говорите что сфера другая. Энтити, это всего-лишь цикл, но цикл не для массива, а для всего приложения + само название говорит что работа будет происходить не с объектами, а их сущностями. Сейчас мода это виртуальный дом, который можно рендерить на сервере. Но с энтити можно было бы рендерить на сервере + Вы бы не видели разницы в работе с домом. То есть в angular2, реакте и им подобным фраймворкам есть одна большая проблема, все новые приблуды в виде библиотек компонентов, всякие скролы и прочие нужно ещё подогнать под эти фраймворки. А теперь представьте что Вы можете скачать самые красивые и модные компоненты и работать с ними в Вашем фраймворке. И при этом прирост в производительности огромный, особенно для сложных анимаций. А так или иначе эти сложные анимации должны встречаться все чаще и чаще.
И главно что все так же можно писать кастомные компоненты и добавлять в них логику.