ну там не shadow dom, там таргетное измение так сказать

Аххаха. Это я Когда писал про пои и тебя закидали помидорами а щас - "вау крутая вещь"

Аххаха. Это я Когда писал про пои и тебя закидали помидорами а щас - "вау крутая вещь"

это мое личное мнение, и сейчас походу в сети мало людей которые помидорами кидаются

я не видел, чтоб ты такое писал

Мне пои нравится очень. Как и многое от эгоиста

я не видел, чтоб ты такое писал

Давно уже

Мне пои нравится очень. Как и многое от эгоиста

а че еще интересное есть? кроме ream?

или как его там

которые ssr из коробки дает

когда релиз? хотю-хотю

кстать, не заметил, что в ветке next, Эван каждый день кучу коммитов делает в vue cli

Аххаха. Это я Когда писал про пои и тебя закидали помидорами а щас - "вау крутая вещь"

мне особо в пой понравился рецепт https://poi.js.org/#/recipes/progressive-web-app

я 2 дня не мог определить че заюзать из плагинов для вебпака, чтоб пва врубить

жаль, я в конечном итоге какой-то workbox заюзал от гугла

а че еще интересное есть? кроме ream?

Там у него многое. Мелкие всякие штуки, плагины под вью, для сборки

сам, что выделяешь?

например мне идея ream тоже нравится, но больно он новый чтоль, и не понятно почему ream просто не расширяет poi

кстать, не заметил, что в ветке next, Эван каждый день кучу коммитов делает в vue cli

Не, не смотрел, я с телефона тот .md файл чекал

Bili и вуепак

Не, не смотрел, я с телефона тот .md файл чекал

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

Я тоже, но сорсы не читаю, слишком это ущербно для меня смотреть исходники с телефона

Bili и вуепак

хе, мне первое не понятно (еще один парсел или наоборот), а вуепак ничем от vue webpack не отличается почти)

хе, мне первое не понятно (еще один парсел или наоборот), а вуепак ничем от vue webpack не отличается почти)

Сборщик модулей. Плагинов и прочего. Под капотом роллап Типа пои только для сборки не проекта а библиотеки

Сборщик модулей. Плагинов и прочего. Под капотом роллап Типа пои только для сборки не проекта а библиотеки

а

Юзабельная херня

Меня вообще прельщает автоматизация всего. Да - иногда нужно что то специфичечкое. Но оно не должно занимать несколько сот линеек конфига как в случае с вебпаком

Мне вот на днях пришлось заюзать rollup для сборки d3.js потому что webpack не делает для нее tree shaking, вот когда у тебя конфиги можешь сам все подкрутить добавить, а вот все эти штуки, когда из коробки оно само все решает, пугают тем, что в нужный момент ничего дотюнить не сможешь.

Хотя и перегибы в другую сторону, когда скрипты webpack-а, сложнее самого проекта, тоже не дело :)

сегодня css in js, а завтра порнуха без баб

золотые слова!

шаблонизатор без хтмл )

при мне использовали SimpleXML как шаблонизатор в PHP. 14 мб отличного говнокода. если кто из ООО Сервис ТВ, тем привет

Всем привет, подскажите, пожалуйста кто знаком с vue-yandex-maps. Карта инициализируется ни каких ошибок нет, но ширина карта выставляется в 0. Как это можно поправить?

Вопрос к осуждающим подход JSX - вам код на React вообще приходилось писать? Особенно так, чтобы реально какой-нибудь сложный проект?

Не приходилось, но осуждаю))

Вопрос к осуждающим подход JSX - вам код на React вообще приходилось писать? Особенно так, чтобы реально какой-нибудь сложный проект?

У нас сейчас пишется проект на react + redux + etc (spa). Этот проект планируем тиражировать по клиентам и под каждого свои доработки. Главная Задача - минимизировать время (а следовательно и стоимость) доработок и дальнейшей поддержки иначе будем не конкурентноспособны. А наш штат прораммистов должен в это дело быстро вьехать и уметь модернизировать, т.к. сейчас используется другие технологии. Я недавно начал анализировать, то что уже сделано у нас. И пока у меня стойкое ощущение, что легче всё переписать на vue. Ибо jsx с его кашей из кода и верстки - это дикий ужас, придуманный обкуренным индусом. Ну или очередной брейнфак for fun внезапно стрельнувший. А redux - это костыль, который потом героически затыкается всякими имунтаблями, обсерваблями и милдваблями с сагами.

Не приходилось, но осуждаю))

Это так все хейтеры jsx делают?

И почему это Redux костыль?

И почему это Redux костыль?

Ну отвечу вопросом на вопрос. Для чего нужен, к примеру, immutable ?

Вопрос к осуждающим подход JSX - вам код на React вообще приходилось писать? Особенно так, чтобы реально какой-нибудь сложный проект?

Нука-нука, расскажи, какие стратегические преимущества даёт jsx для вью

а как мне из одного компонента обратиться к свойству другого?

или отреагировать на действия другого

два компонента, две таблицы, по нажатию одной кнопки надо обе очистить

В каких отношениях состоят ваши компоненты?

Муж-жена или родитель-ребенок?

они просто рядом

в принципе я могу сделать это через бэкенд, через вебсокеты, но как-то... костыльно получится

vuex

они просто рядом

Слушаем в родителей событие с компонента А и обновляешь по нему пропсу для компоненты Б

Слушаем в родителей событие с компонента А и обновляешь по нему пропсу для компоненты Б

Это примерно так? https://medium.com/@modex13/vue-js-2-передача-данных-между-компонентами-467383294847

Нет

сделать одну из компонент родительской и тогда как в статье?

В компоненте А посылаешься событие через emit, в родителей его слушаешь В листенере изменяешь какую-нибудь специальную пропсу для компоненты Б

ну так а что не так по ссылке?

ну так а что не так по ссылке?

Там передача данных между родителем и потомком. У тебя судя по ТЗ - компоненты соседи и подойдёт оттуда только bus - а это зло

ну я засуну одну таблицу в другую, так сказать

логически оно верно будет

о, тогда собственно и эмит не нужен будет

Immutable для предотвращения изменения данных

Например

ну так а что не так по ссылке?

Там обращение непосредственно к функциям через $parent и $children[]

А это можно использовать тогда и только тогда, когда ствол к башке приставлен

Потому что это завязка на непубличные интерфейсы компонент

const x = { counter: 0 } const y = x.counter;

И пиздец

Ну отвечу вопросом на вопрос. Для чего нужен, к примеру, immutable ?

А зачем вообще нужна имутабельность?

А зачем вообще нужна имутабельность?

Бинго

Нука-нука, расскажи, какие стратегические преимущества даёт jsx для вью

Высокая гибкость. Бывает полезно для реализации сложной логики в UI

В redux можно же юзать Object.assign либо ...state

Высокая гибкость. Бывает полезно для реализации сложной логики в UI

Ещё раз, это завязка на НЕ публичные методы компоненты

Ты можешь их использовать ТОЛЬКО тогда, когда ты ГАРАНТИРУЕШЬ, что эти методы есть в компонентах и что НЕ будет изменяться их порядок

В redux можно же юзать Object.assign либо ...state

Спреад кстате быстрее

Мне как то норм без immutable

Т.е допустим если ты такие обращения делаешь в глобальном миксине - это ок, а если ты в компоненте Х делаешь children[0] то ты обязан как-то гарантировать, что порядок всегда будет константным

Проблем нет как то

А обязательно ли явно обозначать arrayOf(React.element)

Проблем нет, потому что у вью реактивность и в дев режиме она за всем следит

В проверках типов

У реакта реактивности данных - нет, поэтому им нужна иммутабельность

Кто-нибудь делал большое приложение на Vue, с большим количеством компонентов? По советуйте что почитать по по архитектуре и структуре масштабируемого приложения. Может есть примеры на гитхабе?

Кто-нибудь делал большое приложение на Vue, с большим количеством компонентов? По советуйте что почитать по по архитектуре и структуре масштабируемого приложения. Может есть примеры на гитхабе?

Я не встречал

У меня на работе порядка 150-200 компонент и просто масштабируется все

У меня на работе порядка 150-200 компонент и просто масштабируется все

Может и больше ?

Immutable для предотвращения изменения данных

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

У реакта реактивности данных - нет, поэтому им нужна иммутабельность

Вы, кажется, соотносите мягкое с тёплым.

У меня на работе порядка 150-200 компонент и просто масштабируется все

В vuex модули используете?

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

Основная задача - это консистентность данных, а быстрое клонирование - это лишь оптимизация.

В vuex модули используете?

Да

Вы, кажется, соотносите мягкое с тёплым.

Отнюдь

Основная задача - это консистентность данных, а быстрое клонирование - это лишь оптимизация.

сначала выдумали гемор, потом оптимизация этого гемора. Притянуто конечно, но суть отражает

mobx как то лучше выглядит

Отнюдь

Приду на работу, напишу доказательство

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

Грубо говоря есть у вас асинхронный экшен, в который vuex передаёт state. После выполнение первой асинхронной функции во Vuex нельзя быть уверенным, что в том state, который находится в скоупе данные всё те же, которые были перед вызовом асинхронной функции, от этого могут возникнуть серьёзные проблемы.

Конечно в однопоточных приложениях js, где минимальной единицой исполнения является последовательность синхронных действий, это не так существенно, но в многопоточных приложениях это создаёт невероятную боль.

Я не встречал

Приходите на митап в Москве там поболтаем, я расскажу как выстроена у нас архитектура

Блокировки, глобальные флаги и прочее подобное счастье - следствие мутабельности.

Грубо говоря есть у вас асинхронный экшен, в который vuex передаёт state. После выполнение первой асинхронной функции во Vuex нельзя быть уверенным, что в том state, который находится в скоупе данные всё те же, которые были перед вызовом асинхронной функции, от этого могут возникнуть серьёзные проблемы.

слишком дорого обходится решение, которое можно решить точечно, где это необходимо.

слишком дорого обходится решение, которое можно решить точечно, где это необходимо.

Дорого это обходится лишь иногда. А чтобы определить где же именно происходит это иногда, нужно профилировать уже готовое приложение.