ВГ
Вот мы сейчас и узнаем, насколько свелт сообщество-ориентирован
Size: a a a
2020 November 02
˸A
Вот мы сейчас и узнаем, насколько свелт сообщество-ориентирован
Сообщество vs качество
Let's fight!
Let's fight!
ВГ
Качество субъективно, конкретно в этом вопросе
ВГ
Предложенный RFC приводит к ситуации, когда у компонента может быть обертка, а может быть и нет. Если компонент по какой-то причине обращается к родительским элементам, то добавление обертки сломает его
ВГ
А чтобы добавить обертку, достаточно будет добавить --параметр
˸A
Качество субъективно, конкретно в этом вопросе
Не соглашусь. Уже затащили многое, что мне не нравится. Я писал выше об этом
https://t.me/sveltejs/114635
https://t.me/sveltejs/114635
AP
Да можно руками обернуть в див если надо. Это не такая сложная задача, только на этот див уже можно класс повесить в котором все переменные определить + каскады.
AP
Да и нет никакой сложности в юзерленде сделать компонент со слотом, который будет делать тож самое
<VariablesProvider --var-1={1}>
<ChildComponent/>
</VariablesProvider>
он хотябы безусловно врапать можетPM
При этом я-то вообще против класс форвардинга и за цсс переменные (херачу проект уже давно и никогда классы форвардить не надо было, всегда справляюсь переменными). Всё, что я сказал — это что решение тащить в кор смысла нет, потому что оно решено в юзерленде и там не сыскало популярности.
На что меня назвали оппозиционером, приобщили к группе, которая всегда против всех фич, на серьезных щщах сравнили установку пакета из NPM с написанием кастомного компиляторного макроса.
Я хз, видимо, им там совсем много говна приходится разбирать, раз они так агрессивны.
На что меня назвали оппозиционером, приобщили к группе, которая всегда против всех фич, на серьезных щщах сравнили установку пакета из NPM с написанием кастомного компиляторного макроса.
Я хз, видимо, им там совсем много говна приходится разбирать, раз они так агрессивны.
у меня точно такая же позиция. RFC не решает ничего, даже того что мог бы решать:
1) автоматически вешать переменные на все рут-теги чайлда (первая версия рфц)
2) решать проблему с глобальными именованием переменных (не всегда это надо, но хотя бы что-то)
1) автоматически вешать переменные на все рут-теги чайлда (первая версия рфц)
2) решать проблему с глобальными именованием переменных (не всегда это надо, но хотя бы что-то)
AP
у меня точно такая же позиция. RFC не решает ничего, даже того что мог бы решать:
1) автоматически вешать переменные на все рут-теги чайлда (первая версия рфц)
2) решать проблему с глобальными именованием переменных (не всегда это надо, но хотя бы что-то)
1) автоматически вешать переменные на все рут-теги чайлда (первая версия рфц)
2) решать проблему с глобальными именованием переменных (не всегда это надо, но хотя бы что-то)
дак а как в общем случае решить проблему с глобальным именованием, автоматически переменные незаскоупить
AP
переменные определенные в родителе никак не связать с переменными использованными в детях
PM
дак а как в общем случае решить проблему с глобальным именованием, автоматически переменные незаскоупить
не понял что именно ты выразил) заскоупились и добавились к чайлду и из-за уникального имени доступны только ему
AP
механизм скоупинга не ясен
PM
переменные определенные в родителе никак не связать с переменными использованными в детях
вот именно, никак в userland,
AP
даже в компайлере
AP
тебе нужен будет кросскомпонентный чек тогда какой-то, либо я хз как это делать
PM
даже в компайлере
почему это? закидывает в компоненты эти пропсы:
new Component({
...
styles: {}
})AP
дак они же должны быть доступны всему дереву ниже, это целый контекст получается
PM
компонент, ищет все рут-теги и туда вещает переменные с хэшами, ищет места их использования в css и туда тоже вписывает хэши
AP
как их использовать в цсс?