Комментарии 30
Каждый раз не перестаю поражаться, как же изобретательно люди могут решать проблемы, которые сами себе и создали (это я про doNotRender, но впрочем передача классов и стилей через реактовские пропсы под это тоже прекрасно подходит).
Не понял, какие проблемы вы имеете в виду. Есть задача: скрывать элемент формы, если другой элемент имеет значение. Не вижу тут проблемы, которую «я создал сам себе».
В теории можно не прибегать к использованию conditional rendering внутри блоков JSX. Решение: для каждого такого случая делать обертку компонента. Но на практике это превращается в бесполезную трату времени для разработчика.
В теории можно не прибегать к использованию conditional rendering внутри блоков JSX. Решение: для каждого такого случая делать обертку компонента. Но на практике это превращается в бесполезную трату времени для разработчика.
Не понял, какие проблемы вы имеете в виду.
Проблема: JSX выразительно убог.
Решение: сделаем компоненты, которые на самом деле могут себя не рендерить вообще, во имя победы над убогостью JSX.
Вы серьезно не видите, что это классическое «поищем ключи под фонарём, не потому, что их под фонарем потеряли, а потому что светло»? Впрочем, в нынешние времена полвёба так задачи решает… В css есть известные проблемы модульности? А давайте стили в яваскрипте писать! Протокол HTTP/1.1 имеет определенные проблемы с масштабируемостью? Давайте напишем миллионы бандлеров, RPC, проксирующих нод, наконец — всё, кроме решения проблем собственно HTTP/1.1.
PS: А потом, когда HTTP/1.1 уже медленно, но верно отправляется на свалку истории, и я предлагаю людям уже наконец не страдать бессмысленной переупаковкой ресурсов, на меня смотрят круглыми глазами и вопрошают «но как?! браузер же будет долго-предолго грузить много ресурсов!!».
Какие еще есть api для написания компонентов, кроме React.createElement и синтаксиса JSX?
Осподи. Тысячи их. Модуляризируется всё, начиная от ангуляра (впрочем я бы конечно не советовал тащить ангуляр, чтоб слепить с ним один компонент, но это безусловно возможно) и vue, и заканчивая вебкомпонентами и чем-нибудь типа svelte.
Вы как будто в 2010 году ушли в анабиоз и проснулись вчера.
Вот например на этой странице хоть и далеко не всё имеет отношение к компонентной разработке, но я бы сказал, что как минимум процентов 70% страшных названий из тех таблиц — или позволяют напрямую писать компоненты, или предлагают какой-то почти пригодный для этого API. А вы спрашиваете «а что есть-то?».
Вы как будто в 2010 году ушли в анабиоз и проснулись вчера.
Вот например на этой странице хоть и далеко не всё имеет отношение к компонентной разработке, но я бы сказал, что как минимум процентов 70% страшных названий из тех таблиц — или позволяют напрямую писать компоненты, или предлагают какой-то почти пригодный для этого API. А вы спрашиваете «а что есть-то?».
Vue? Ему хоть свои шаблоны, хоть jsx, хоть рендер-функции…
А давайте стили в яваскрипте писать!
В яваскрипте их писать, конечно, глупо, а вот в тайпскрипте — имеет свои преимущества. Такие как подсказки и тайпчекинг с учётом иерархии компонент.
а вот в тайпскрипте — имеет свои преимущества
Имеет. Но всё так же избавляется от большинства преимуществ собственно css.
Каких, например?
Гораздо легче перечислить то, что останется: останется работа со стилями а-ля инлайновая подстановка. Практически всё, связанное с каскадностью цсс — будет потеряно без очень вольного допущения, что всё, что желает перекрыть ваши стили адекватным образом — будет обязано использовать то же CSS-in-JS решение, что и использовано у вас в коде. Впрочем, про перекрытие, скажем, в конкретном юзерском браузере через user stylesheet всё равно можно будет забыть.
Я просто оставлю это здесь: https://github.com/eigenmethod/mol/tree/master/style
Давайте напишем миллионы бандлеров
Загрузили один скрипт, там импорт, загрузили следующий, там тоже импорт, и так 20 раз. Это очень медленно. Любое решение этой проблемы предполагает сборку бандла в каком-либо виде.
Загрузили один скрипт
Вы ошибаетесь уже в первом пункте.
Скрипт не обязательно «загрузить», чтоб обнаружить в нем импорт. Импорты сверху. Достаточно лишь начать его грузить.
Не важно, для глубины в 20 уровней это будет пинг*20.
Во-первых, пинг и latency — это не одно и то же. Во-вторых — конечно будет. И? Это далеко не всегда имеет какое-то значение даже если не вспоминать про локальный кеш. Или про то, что глубина имеет практический предел роста.
В данном случае именно пинг — надо дождаться ответа от сервера, чтобы понять что грузить. Вот у меня сейчас на 4G пинг 80мс, что для глубины 20 даёт полторы секунды задержки. Тупо из-за отсутствия бандлинга.
Вот у меня сейчас на 4G пинг 80мс, что для глубины 20 даёт полторы секунды задержки. Тупо из-за отсутствия бандлинга.
А у меня бывает вайфай с 10% потерей пакетов, из-за чего загрузка бандлов больше мегабайта имеет задержку в «бесконечность». Что дальше?
80мс — это очень хороший пинг для мобильного интернета, так что 1.5.с — это очень оптимистичная оценка.
Невозможность на практике загрузить любой блоб больше мегабайта — это тоже оптимистичная оценка, я видел ситуации и похуже.
Еще раз, что и кому вы пытаетесь доказать? Что отсутствие бандлинга имеет свою цену? Бандлинг тоже имеет свою цену. Вообще всё имеет свою цену.
Еще раз, что и кому вы пытаетесь доказать? Что отсутствие бандлинга имеет свою цену? Бандлинг тоже имеет свою цену. Вообще всё имеет свою цену.
Что никакой HTTP/2/3/4 принципиально не может решить проблемы, решаемые бандлингом.
Это высказывание а-ля «теплое не решает проблем, решаемых круглым».
Транспортный слой и способ упаковки ресурсов — это две разные вещи, и, чёрт возьми, невероятно логично, что проблемы, решаемые первым и вторым — они разные.
Транспортный слой не может вас заставить привести ваши ресурсы в оптимальный для скорости передачи вид; и поэтому вам конечно же никто не запрещает фантазировать про глубину в 20 модулей. Но бандлинг — это не более чем один из частных способов приведения ресурсов к таковому виду. Есть и другие: например, любую структуру модулей добавлением импортов можно всегда привести к глубине 2. А размещение этого основного блока импортов инлайново в html — даст глубину 1.
Транспортный слой и способ упаковки ресурсов — это две разные вещи, и, чёрт возьми, невероятно логично, что проблемы, решаемые первым и вторым — они разные.
Транспортный слой не может вас заставить привести ваши ресурсы в оптимальный для скорости передачи вид; и поэтому вам конечно же никто не запрещает фантазировать про глубину в 20 модулей. Но бандлинг — это не более чем один из частных способов приведения ресурсов к таковому виду. Есть и другие: например, любую структуру модулей добавлением импортов можно всегда привести к глубине 2. А размещение этого основного блока импортов инлайново в html — даст глубину 1.
Когда вы разрабатываете компонент, вы не можете сделать его полностью универсальным.
Я целый фреймворк построил на идее полностью универсальных компонент, которые можно собирать в любых комбинациях...
Для чего вы изобретаете кнопку из div'a, если для этого есть специальный тег , который уже реализует часть функционала необходимого для кнопки из коробки?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Унификация визуальных компонентов. Часть 1. Стили