классов?
Мне как-то это меньше нравится, дольше писать эти стайлед компоненты, подключать/импортить
Он реально медленнее обычного css
а реакт медленне чем DOM )
где-то уже обсуждалось что не критично медленнее
За счёт чего? Объясни если разбираешься При сборке все стайлд компоненты превращаются в классы (вроде)
Ты че высрал?😄
Зумерочек, с таким именем + разговорами тебе точно не в этот канал)
Обычной библиотекой назову. Вот ангуляр - Фреймворк
фреймворк - крупная библиотека. Всего лишь. Остальное лишь СПГС различных надмозгов
Нет. Это лишь крупная библиотека, решающая определенный спектр задач.
что такое «крупная»?
это какие же?) и тут такой вопрос что тут как раз стоит вдавать в подробности а вот lodash это не три функции, а очень много функций. Это делает его ближе к фреймворку?
Ну, если отдельно рассмотреть функции работы с объектами, то можно сказать "lodash - фреймворк для работы с объектами".
А кому он должен что-то говорить? Он дает инструменты создания каркаса согласно своей структуре и задумкам, которые в него вложили. Вот и всё.
Всем. Он должен четко реграментировать правила написания приложения. Ангуляр говорит. Spring говорит. Реакт нет. “Инструмент” и “is-odd” дает, регламент - нет.
Кому должен-то и по чьему велению?
Определение не у меня, ты сам его даже цитировал. Более того, оно исходит из самого слова, если просто его перевести
Ты не поверишь...
Поверю, ведь он не реактивный
Цитировал не я, а перевод не имеет значения
В моем аппарате - это вот. Дословно. И спор уже состоится_
Что в твоем понимании “платформа, определяющая структуру программы”? Вот к тому же лодашу, ты писал “Но можешь назвать lodash фреймворком по созданию и обработке объектов. Странное развлечение, но семантически верно”. Получается, lodash определяет структуру программы? Если да, то как? Если нет, то как это можно “семантически верно” назвать фреймворком?
“Компонентный подход” - пустота, это ничто. Код в функцию вынес и в другой функции юзаешь - о ля, компонентный подход у меня. "файловая структура в 99% схожа” - ну, 1) кул стори 2) это не регламентирует реакт 3) соглашения !== фреймворк 4) это мусорка, а не результат того, что в проекте за основу взята “платформа, определяющая структуру программы” "А то, что тебе должны или не должны навязывать” - это определение, чел. Я чот подзаебался и выстрелил себе в ногу, сказав, что человек выдумал себе определение и спорить с ним физически не возможно, т.к. это спор с использованием одних и тех же терминов, но, сука, с разными значениями, но, блэд, начал спорить ъуъ. Ладно, в выдуманном мире собственных определений жить удобно.
Считай, как тебе угодно. Я разве грозил тебе голову отбить за иное мнение? Можешь хоть компонентой назвать. Ради бога. Цели переубедить у меня и не стоит.
Я не говорил, что он появился там. Я сказал, что основа реакта - компонентный подход, который и определяет структуру.
Как это относится к структуре программы? Подробленные функции будут вызываться каскадом, это просто декомпозиция. Декомпозиция приводит к дроблению и каскадному обобщению/подключению
В чистом js тоже можно сделать декомпозицию, но он же никак не определяет структуру
Дело не в композиции, а буквально в том, как работает инструмент. Можно использовать реакт и без композиции, можно все напечатать в одной компоненте. Но зачем тогда использовать этот инструмент?
напиши на реакте приложение без иерахнической СТРУКТУРЫ компонентов.
Ты не понял, иерархия компонентов не влияет на структуру приложения. Это требование исходит из самой декомпозиции. Требование есть, а структуры нет
нет не следует. примеры выше привел
Я заметил тенденцию, всегда когда ты с кем то споришь, всегда ты не прав
Мощный аргумент)
Я много с чем работал и все говно стабильно забываю. Ну не суть, словами-то всегда можно схемку накинуть. Вот три странички, на них табы копипастой, захотел ты декомпозировать и переиспользовать - че делать будем без иерархии?
я могу в выходные сдунуть пыль с доки бекбона, и изучить этот вопрос
папочки… структура.. понятно
Ну чот получается, что иерархия-то есть, а куда ей пропасть-то, это же физически невозможно - мы не можем разделить функцию const sumAndDiv = (a, b, c) => (a + b) / c; на функции sum и div без связывания их где-то выше, это же бред, не так ли? Ну так и везде, где есть декомпозиция, будет ебучая иерархия. То, что она выглядит не так явно, как с компонентиками - ну, понятное дело, многие инструменты то еще говно https://github.com/dmytroyarmak/backbone-contact-manager/blob/gh-pages/app/js/views/contacts.js
Обсуждают сегодня